search

Juris-M / zotero

Juris-M is a variant of the free and friendly Zotero research platform, with support for legal and multilingual materials.
https://juris-m.github.io
Other
77 stars 12 forks source link

Better BibTeX in Juris-M #16

Closed retorquere closed 8 years ago

retorquere commented 8 years ago

I've tried installing the latest BBT in Juris-M, but I'm getting this error when I import some items (using the debug translator built into BBT). I've tried figuring out what the relevant differences are between Zotero 4.0 and Juris-M, but the code mentioned in the trace seems very similar:

(2)(+0000000): Translate: Translation using BetterBibTeX JSON failed:
string => Error: Invalid field 'false' in ItemFields.isBaseField()
stack => _fieldCheck@chrome://zotero/content/xpcom/data/itemFields.js:410:1
isBaseField@chrome://zotero/content/xpcom/data/itemFields.js:216:3
Zotero.Utilities.itemFromCSLJSON@chrome://zotero/content/xpcom/utilities.js:2342:8
Zotero.Translate.ItemSaver.prototype._saveFields@chrome://zotero/content/xpcom/translation/translate_item.js:674:4
Zotero.Translate.ItemSaver.prototype.saveItems@chrome://zotero/content/xpcom/translation/translate_item.js:132:7
Zotero.Translate.Base.prototype._saveItems@chrome://zotero/content/xpcom/translation/translate.js:1425:1
Zotero.Translate.Sandbox.Base._itemDone@chrome://zotero/content/xpcom/translation/translate.js:150:5
Zotero.Translate.SandboxManager.prototype.importObject/attachTo[localKey]<@chrome://zotero/content/xpcom/translation/translate_firefox.js:527:29
@resource://gre/modules/RemoteAddonsParent.jsm:761:66
Zotero.Item.prototype.complete@resource://gre/modules/RemoteAddonsParent.jsm:761:448
doImport@/tmp/webdriver-rb-profilecopy20160409-28874-rkupna/zotero/translators/BetterBibTeX JSON.js:1697:18
Zotero.Translate.Base.prototype._translateTranslatorLoaded@chrome://zotero/content/xpcom/translation/translate.js:1222:4
Zotero.Translate.Base.prototype.translate/<@chrome://zotero/content/xpcom/translation/translate.js:1189:58
Zotero.Translate.Import.prototype._loadTranslatorPrepareIO/initCallback@chrome://zotero/content/xpcom/translation/translate.js:2051:17
Zotero.Translate.IO.Read.prototype.init@chrome://zotero/content/xpcom/translation/translate_firefox.js:938:3
Zotero.Translate.Import.prototype._loadTranslatorPrepareIO@chrome://zotero/content/xpcom/translation/translate.js:2078:3
Zotero.Translate.Import.prototype._loadTranslator/<@chrome://zotero/content/xpcom/translation/translate.js:2034:3
Zotero.Translate.Base.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:1574:16
Zotero.Translate.Import.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:2033:2
Zotero.Translate.Base.prototype.translate@chrome://zotero/content/xpcom/translation/translate.js:1189:4
Zotero_File_Interface</_importTranslatorsAvailable/<@chrome://zotero/content/fileInterface.js:355:5
fbennett commented 8 years ago

It may take a few days for me to get to it, but I should be able to help. How can I go about running the tests?

retorquere commented 8 years ago

I've just put up an explanation on how to run the BBT test suite on my wiki. In the case of Juris-M there are just a few changes.

  1. After cloning, checkout the 475 branch. This is just current master, but it has a few tweaks so Juris-M is available as an option in addition to Zotero.
  2. Set JURIS_M=true in your environment. This will cause the test runner (in the 475 branch, I haven't merged it yet, but I will) to grab Juris-M instead of Zotero. Something like JURIS_M=true SIGN=false rake test should do the job.

The circle.yml in that branch has JURIS_M set to true; I think it will just work if you flick the switch in your clone, but I haven't tried.

Thanks for looking into this!

retorquere commented 8 years ago

You probably know BBT is a little immodest about going in and groping around -- I don't expect you to just get BBT working, but I seriously don't understand what's failing above, and that error is in the setup for the first test.

But my initial report was misleading. The bulk of the tests actually pass, and some of the failing tests are not hard to address. The test that failed just happened to be a) big and b) the first. It's still odd though. It fails at the import part (that part I got right above), but all tests run this part in one way or the other. Why it should flame out in that part of these tests is still a mystery to me.

retorquere commented 8 years ago

Interesting -- CSL title, volume-title, container-title=BL title, booktitle, maintitle #381 appears to fail because (I think) Juris-M strips out volume-title: ... from the extra field before BBT sees it. Is that information available elsewhere to the translator?

retorquere commented 8 years ago

No, that isn't right, the data is still there. NM.

fbennett commented 8 years ago

Yeah, it could take me awhile to set up your test framework, and from the docs it sounds like it would be hard to do my usual thing of sticking comments in the code to try hypotheses. Is there an operation I can perform user-side in a client with BBT installed that will trigger the failure you're seeing?

retorquere commented 8 years ago

I haven't tried, but you should be able to unzip the latest release and run it as per running git installations. Just make sure that any changes you want to make to the translators you make in the bundled .translator files in resource/translators, not to the ones that get installed into the Zotero translators directory, as BBT overwrites those every time it starts up.

The translator files are big as a lot of cruft gets bundled in because I need them inside the sandbox; most of the code is library code, I've marked the sections by SOURCE: comments. And they're generated from coffeescript sources, so it's not always the prettiest JS to look at.

Comments is how I usually do it though, except I put the comments in coffeescript code. I know of no other way, but I haven't actually tried the Mozilla debugger. Huh.

fbennett commented 8 years ago

Actually, this looks like a straight-up bug in Juris-M code. I owe you.

From the steps in the trace at the top of this thread, it looks like it's failing on a date variable. Juris-M adds a bunch of date variables to the schema (schema changes here, mappings to CSL here). It looks like it's finding a date variable okay (so it has a value for field in utilities.js), but then it's not finding an ID for it, so fieldID in that function is set to false. When that is fed to isBaseField(), it blows up. It's a little confusing if the code is read by following functions from the top of the trace, because the field argument in Zotero.ItemFields.isBaseField() is actually coming from the fieldID variable in the calling code.

Anyway, that all points clearly to a mismatch in my code. There must be a date variable in the mappings that is not included in the schema. I'll look into this, it should be an easy fix.

fbennett commented 8 years ago

Oh, jeez, bingo. The Z->CSL date mappings in Zotero are one-to-one, but Juris-M maps one-to-many: the mapping is to an array. So I need to step through those values, but instead I'm treating them as string variables (keys) in their own right. No way that could work.

I do remember covering this issue, but I must have missed this bit, or the code got reversed at some point. The next Juris-M release should do better for you.

retorquere commented 8 years ago

Cool. Also thanks for the pointer to the fields, I have no idea yet how any of those map out to BibTeX, but from the looks of it they should at least be easy to access.

I hadn't thought to look in the schema. It makes sense that the different schema might affect otherwise same or similar code.

What is the meaning of the meta hash that's sometimes included in the author data? The only time I've seen it it has value { '_key': {} }

Do you know of any BibTeX-specific stuff when it comes to legal citation?

fbennett commented 8 years ago

The multi segment is attached to the item, and to individual creators. It carries multilingual variants and language tags dependent on a headline field. It's used both in Zotero items and in CSL JSON (the structures are the same, but in a Z item schema IDs are used, while CSL JSON uses fieldnames). For a field it looks like this when used (main can hold language tags of the headline fields themselves):

{
    'id': 'muzzlemuzzle',
    'title': 'Title in English',
    'multi': {
        'main': {
            'title': 'en'
        }
        '_keys': {
            'title': {
                'ja-JP': '日本語の題名'
             }
        }
    }
}

For creators, the 'field' is known, so the structure is a little simpler. To help keep myself straight on the two, creators use a '_key' hash (singular):

{
    'given': 'Frank',
    'family': 'Bennett',
    'multi': {
        'main': 'en',
        '_key': {
            'ja-alalc97': {
                'given': 'フランク',
                'family': 'ベネット'
            }
        }
    }
}
fbennett commented 8 years ago

On legal LaTeX, you might check out the discussion list hosted by Alan Feldman in New York (he is a New York attorney, and uses LaTeX in his practice). I think the leading package for law is jurabib, but I don't know much about it.

Years ago, I fashioned something out of BibTeX that could sort of handle "Bluebook citations." I stuck with it for awhile, taking it through one major revision, but finally let it go. Law doesn't lend itself to the BibTeX data model; in the US alone, there are over a dozen discrete styles for referencing cases, depending on the jurisdiction in which they are cited. Internationally, the situation is much worse. The only way to handle it without going nuts is to load jurisdiction-specific styles on demand, which is what I do in citeproc-js. It's been like taking off a tight pair of shoes.

For really robust legal support in LaTeX, I think it would make sense to build a wrapper around citeproc-js, and run it as a drop-in replacement for BibTeX, applying CSL (or CSL-M) styles directly to LaTeX source documents. Looking at Oren Patashnik's piece on the desiderata for BibTeX 1.0, citeproc-js covers all of them. Implementing a wrapper would get you there in one go. Lots of leverage to be had, I figure someone will eventually give it a try.

retorquere commented 8 years ago

Wow, not going there. Perhaps then just support for people who want to use Juris-M in Zotero BibTeX mode.

I do remember one of my users pulling out a bibliography over the embedded webserver using a custom CSL style. Someone might already be doing it.

fbennett commented 8 years ago

I've put up a new beta (jurism-v4.0.29.6m64beta7-fx.xpi) that is meant to fix this. Haven't tested it, but this should get you past that error.

fbennett commented 8 years ago

Have now managed to break CSL JSON import in the old Juris-M client version, on a date record that now clears under beta7, so the basic error should definitely go away. The BibTeX recorded on import is _us_????, though, so maybe some tweak will be needed there. Thanks so much for reporting this, that was an ugly bug.

retorquere commented 8 years ago

My pleasure, glad I didn't waste your time. Tests are running on b7.

What do you mean by "The BibTeX recorded on import"?

retorquere commented 8 years ago

I'm now getting

(1)(+0000001): TypeError: Zotero.EXTENDED_FIELDS[zoteroType] is undefined
    ===== Stack Trace =====
    Zotero.Utilities.itemFromCSLJSON@chrome://zotero/content/xpcom/utilities.js:2343:1
    Zotero.Translate.ItemSaver.prototype._saveFields@chrome://zotero/content/xpcom/translation/translate_item.js:674:4
    Zotero.Translate.ItemSaver.prototype.saveItems@chrome://zotero/content/xpcom/translation/translate_item.js:132:7
    Zotero.Translate.Base.prototype._saveItems@chrome://zotero/content/xpcom/translation/translate.js:1425:1
    Zotero.Translate.Sandbox.Base._itemDone@chrome://zotero/content/xpcom/translation/translate.js:150:5
    Zotero.Translate.SandboxManager.prototype.importObject/attachTo[localKey]<@chrome://zotero/content/xpcom/translation/translate_firefox.js:527:29
    @resource://gre/modules/RemoteAddonsParent.jsm:761:66
    Zotero.Item.prototype.complete@resource://gre/modules/RemoteAddonsParent.jsm:761:448
    doImport@/tmp/webdriver-rb-profilecopy20160410-24364-1d0qeyx/zotero/translators/BetterBibTeX JSON.js:1697:18
    Zotero.Translate.Base.prototype._translateTranslatorLoaded@chrome://zotero/content/xpcom/translation/translate.js:1222:4
    Zotero.Translate.Base.prototype.translate/<@chrome://zotero/content/xpcom/translation/translate.js:1189:58
    Zotero.Translate.Import.prototype._loadTranslatorPrepareIO/initCallback@chrome://zotero/content/xpcom/translation/translate.js:2051:17
    Zotero.Translate.IO.Read.prototype.init@chrome://zotero/content/xpcom/translation/translate_firefox.js:938:3
    Zotero.Translate.Import.prototype._loadTranslatorPrepareIO@chrome://zotero/content/xpcom/translation/translate.js:2078:3
    Zotero.Translate.Import.prototype._loadTranslator/<@chrome://zotero/content/xpcom/translation/translate.js:2034:3
    Zotero.Translate.Base.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:1574:16
    Zotero.Translate.Import.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:2033:2
    Zotero.Translate.Base.prototype.translate@chrome://zotero/content/xpcom/translation/translate.js:1189:4
    Zotero_File_Interface</_importTranslatorsAvailable/<@chrome://zotero/content/fileInterface.js:355:5
    =======================
fbennett commented 8 years ago

What is the value of zoteroType?

(By BibTeX record, I just meant the input record that triggers the error.)

fbennett commented 8 years ago

There is another obvious flaw in the Juris-M code here, though. Not all Zotero types have been extended, so when no extension information is found, it should drop out of what it wants to do there. Beta8 is now up, hope it does better.

retorquere commented 8 years ago

Do you mean a specific test case of mine when you say "BibTeX record..."?

How can I log the value of zoteroType? As I usually do I monkey patched the function to inspect what's going in and out, but It's an internal var to Zotero.Utilities.itemFromCSLJSON. I can see that cslItem.type = webpage when itemFromCSLJSON is being called, so zoteroType should be webpage if I follow that code correctly.

But beta8 does resolve this error, huzzah! Tests are running again. I can already see there are differences between the Zotero and the Juris-M date-parser causing me to not find dates on some items, or perhaps it's due to the dates being in another field, but that shouldn't be hard to resolve.

retorquere commented 8 years ago

There is something funny going on with CSLvars in the extra field though. All the tests that rely on those values being there currently fail.

fbennett commented 8 years ago

At least we've gotten past the obvious things. I'm doing some writing tonight, and won't be able to look at it, but I'll keep it in thought, might send a note tomorrow morning.

retorquere commented 8 years ago

I should totally be doing some writing tonight and every night for the coming weeks. This is my guilty pleasure... generally good news though, no more errors on importing objects, just exports, and of the 138 tests, 130 pass.

fbennett commented 8 years ago

Oooh. Juris-M scores a B+!

retorquere commented 8 years ago

If I import the attached file, which is a CSL-JSON file exported using Juris-M (no BBT or anything else installed), I get:

(1)(+0000000): TypeError: creator.multi._lst is undefined
    ===== Stack Trace =====
    Zotero.Translate.ItemSaver.prototype._saveCreators@chrome://zotero/content/xpcom/translation/translate_item.js:724:9
    Zotero.Translate.ItemSaver.prototype.saveItems@chrome://zotero/content/xpcom/translation/translate_item.js:136:8
    Zotero.Translate.Base.prototype._saveItems@chrome://zotero/content/xpcom/translation/translate.js:1425:1
    Zotero.Translate.Sandbox.Base._itemDone@chrome://zotero/content/xpcom/translation/translate.js:150:5
    Zotero.Translate.SandboxManager.prototype.importObject/attachTo[localKey]<@chrome://zotero/content/xpcom/translation/translate_firefox.js:527:29
    @resource://gre/modules/RemoteAddonsParent.jsm:761:66
    Zotero.Item.prototype.complete@resource://gre/modules/RemoteAddonsParent.jsm:761:448
    doImport@/home/emile/.mozilla/firefox/mjaevy0p.Juris-M/zotero/translators/CSL JSON.js:63:3
    Zotero.Translate.Base.prototype._translateTranslatorLoaded@chrome://zotero/content/xpcom/translation/translate.js:1222:4
    Zotero.Translate.Base.prototype.translate/<@chrome://zotero/content/xpcom/translation/translate.js:1189:58
    Zotero.Translate.Import.prototype._loadTranslatorPrepareIO/initCallback@chrome://zotero/content/xpcom/translation/translate.js:2051:17
    Zotero.Translate.IO.String.prototype.init@chrome://zotero/content/xpcom/translation/translate.js:2547:4
    Zotero.Translate.Import.prototype._loadTranslatorPrepareIO@chrome://zotero/content/xpcom/translation/translate.js:2078:3
    Zotero.Translate.Import.prototype._loadTranslator/<@chrome://zotero/content/xpcom/translation/translate.js:2034:3
    Zotero.Translate.Base.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:1574:16
    Zotero.Translate.Import.prototype._loadTranslator@chrome://zotero/content/xpcom/translation/translate.js:2033:2
    Zotero.Translate.Base.prototype.translate@chrome://zotero/content/xpcom/translation/translate.js:1189:4
    Zotero_File_Interface</_importTranslatorsAvailable/<@chrome://zotero/content/fileInterface.js:355:5
    =======================

Exported Items.txt

retorquere commented 8 years ago

[A] The problem with the missing fields is not an import issue -- Juris-M strips out CSL fields in the extra field during import. Try importing this attachment (it's in Zotero RDF format) -- it has {:issued:2014-12-31/2015-01-01} in the extra field, but it doesn't show up in Juris-M. Exported Items.txt

retorquere commented 8 years ago

It's not an export issue I meant to say. There's nothing to export.

retorquere commented 8 years ago

I've also tried MODS -- same deal.

retorquere commented 8 years ago

Ugh never mind on the RDF item, it puts it in the abstract. I've attached a BibTeX file exported with the stock translator -- not much roundtrips cleanly.

I think it happens at https://github.com/Juris-M/zotero/blob/jurism/chrome/content/zotero/xpcom/translation/translate_item.js#L660 . I've temporarily monkey-patched Zotero.Utilities.itemToCSLJSON and Zotero.Utilities.itemFromCSLJSON; I can see this being returned from Zotero.Utilities.itemToCSLJSON:

{"type":"webpage","multi":{"main":{},"_keys":{}},"system_id":"0_undefined","title":"Test","note":"{:issued:2014-12-31/2015-01-01}"}

And this coming out of Zotero.Utilities.itemFromCSLJSON, dumped using Zotero.Utilities.Internal.itemToExportFormat (which should give a good idea of what a translator would see):

legacy mode

{"itemType":"webpage","tags":[],"collections":[],"relations":{},"multi":{"main":{},"_keys":{}},"title":"Test","creators":[],"uri":"http://zotero.org/users/local/aMgNMAOC/items/null","attachments":[],"notes":[],"uniqueFields":{"title":"Test"},"itemID":null,"key":null,"dateAdded":null,"dateModified":null,"libraryID":null,"seeAlso":[]}

non-legacy:

{"version":0,"itemType":"webpage","tags":[],"collections":[],"relations":{},"multi":{"main":{},"_keys":{}},"title":"Test","creators":[],"uri":"http://zotero.org/users/local/aMgNMAOC/items/null","attachments":[],"notes":[]}

Given how Zotero.Utilities.itemFromCSLJSON works, I'd have expected issued to be mapped to a field called date, but neither form has that.

Exported Items.txt

fbennett commented 8 years ago

Replying to individual comments doesn't seem to work here, but I can edit your entries for some reason. I tried the attachment in the comment that I have labeled [A] above, both in Juris-M and in Zotero (with BBT disabled), and I get the same result: export in Zotero RDF puts the Extra field content in a "description" node as a sibling to title, etc; and when the item is re-imported, that field content goes into the Abstract field (which can't be right).

I'm not sure what to do there. At first blush, it looks like a bug in the Zotero translator, but there might be a reason for it to behave that way?

Aha. And reading down, I see that you already know that. Late here, I'm going to get some sleep; but I'll read up on your work so far tomorrow, and see if there is anything to do or test at my end.

retorquere commented 8 years ago

Ah don't worry about the rdf, that has never roundtripped properly, it's the main reason I added my debug translator, as it's the only translator that does. Absent the bbt debug translator I usually pick csl-json (not perfect but loads better than rdf when it comes to roundtripping), but Juris-M errors out when importing its own csl-json. That's why I tried rdf, having forgotten how bad it was.

retorquere commented 8 years ago

The main two issues are now a) csl-json import fails (not a problem for bbt, but you might want it to work) and b) the extra field is always stripped of csl-json vars, regardless of which import translator is in use (this breaks the bbt tests, as I need a way to import references that have these after import)

retorquere commented 8 years ago

Or alternatively I need to have access to the data they held in some other fields. But stripping the vars means bbt cannot test what happens if a user manually adds them in the extra field as I can't populate the database that way.

fbennett commented 8 years ago

Found it. During translation, the data in those brace-hack items is being parsed out correctly, but it's stored on the cslItem object as a plain string. When that's fed back to itemFromCSLJSON(), the string value is not valid, so it's dropped on the floor. This would affect both dates and names -- the two main field types for which the brace-hack is useful.

There is code elsewhere that does this parse correctly, so it's just a matter of finding that, casting it as a function if necessary, and then invoking the code during translation. Should have a fix up in a bit.

It should also be possible to improve results in Zotero RDF round-tripping. Zotero RDF sets extra as dc:description, and that's parsed out on import by RDF.js, which handles it as abstractNote, along with bazillion other RDF tags. If dc:description alone is translated as extra by the RDF.js import translator, the brace-hack fields should be recognized there as well. Not sure if that will pass muster in Zotero (RDF is full of mysteries for me), but if it's a hack, it seems a useful one.

More news in a bit ...

fbennett commented 8 years ago

Okay, I have a fix running. The code is in an installed instance of Juris-M, so I'll need to diff it out and merge to the actual source, but we're nearly there.

The fix will apply to both CSLJSON, and to Zotero RDF if the RDF.js translator is patched to put the Extra field data in the right place. I tested with the latter, but it runs itemFromCSLJSON() implicitly, so both translators should be okay.

More soon-ish ...

fbennett commented 8 years ago

Okay, I have a fix running. The code is in an installed instance of Juris-M, so I'll need to diff it out and merge to the actual source, but we're nearly there.

The fix will apply to both CSLJSON, and to Zotero RDF if the RDF.js translator is patched to put the Extra field data in the right place. I tested with the latter, but it runs itemFromCSLJSON() implicitly, so both translators should be okay.

More soon-ish ...

fbennett commented 8 years ago

Try the current beta16 and see how it goes. Should be a bit closer.

retorquere commented 8 years ago

I don't think Zotero-RDF will get to the point that I'll trust it to populate the DB for tests, but I'll take the occasional stab at it. The BBT debug translator simply dumps/loads the JSON all translators are handled, so it's easier to trust that.

One more test passes now, but given that Juris-M moves things from the extra field to dedicated fields, some tests (currently) fail predictably. There's things I can do to make some of those tests pass (just testing for extra fields, no biggie), but I would still need a way to be able to populate the database to start the tests, including putting stuff in the extra fields. I'd either have to do that manually (which is a possibility), but how invasive would it be to have a configOption to allow a translator to flag itself as exempt from the extra-field stripping? Or not even exempt but to leave the data there?

fbennett commented 8 years ago

Yeah, the Zotero RDF fix is more for satisfaction at this end (and for a colleague up the hall who needs it). Re a translator option, do you mean like having a toggle for use in testing that makes Juris-M perform imports without extracting from the Extra field?

retorquere commented 8 years ago

That would one option I could work with, sure; I could have the test runner detect BBT debug import and toggle that preference around the imports.

My ideal to be honest would be that I could have a configOption in the translator header to steer this behavior; I'd really preferably keep everything exactly the same except that I need a way to populate the DB without interference. I can of course have the test suite create items the way a user would normally through the UI, it's just that with Zotero it has been a safe assumption I could populate through a translator (which is heaps easier for me -- not necessarily for you)

retorquere commented 8 years ago

How do the Juris-M tests populate the DB?

retorquere commented 8 years ago

beta16 still strips out {:original-date: XXXX} and doesn't leave the value in any field available to the translators.

retorquere commented 8 years ago

Come to think of it: forget about exceptions for parsing out vars from the extra field. That's actually great, as long as I can find the resulting data in a reference field in the translator.

fbennett commented 8 years ago

Thinking things through a bit, I'm wondering whether this parsing-out-to-native-field thing is actually a good idea. It's good to have the code done, because eventually these extras will be merged into native Zotero; but if a translator makes use of original-date (say), and if it's used in Juris-M to add items to a group shared with Zotero users, only Juris-M will be able to make use of the field.

So (after having gone swings and roundabouts) it's probably better all around to disable that behaviour completely, at least for the present, and leave that stuff in Extra.

The Mozilla signing facility has been down for the past 12 hours, so I can't release a beta with this change yet. But I'm leaning in that direction.

retorquere commented 8 years ago

Urgh yeah I know. They think they've found the problem but nobody is giving me an ETA for signing being available again.

fbennett commented 8 years ago

It's almost as if they're happy we're leaving, but don't quite trust that we will actually jump.

retorquere commented 8 years ago

amen to that. I've been biting my tongue not to scream at them DON'T YOU MORONS TEST?! I DIDN'T WANT TO &#(&#(& BE HERE, AT LEAST MAKE SURE I *CAN BE HERE IF I MUST ARGH ARGH ARGH ARGH.

But I finally have my ETA. "Somewhere today".

Sad to see Mozilla slide that way. I haven't used Firefox for anything but Zotero for years, but I had some sympathy for them, and I actually liked working with XUL better than I like working with Electron. XUL going the way of the dodo is both an understandable choice and the last distinguishing feature they had, so I don't see them surviving in the mid term. If you want open source, there's Vivaldi, Chromium, probably others.

retorquere commented 8 years ago

Signing is back online.

retorquere commented 8 years ago

BTW, what happens if a Juris-M user enters the origdate into the appropriate Juris-M field (so no extra hacks) and then syncs with Zotero?

fbennett commented 8 years ago

At sync it's set in the Extra field in a patch encoded in JSON:

https://www.zotero.org/groups/japanese_judgments_and_rulings/items/itemKey/SNQVWZTN On Apr 16, 2016 07:12, "retorquere" notifications@github.com wrote:

BTW, what happens if a Juris-M user enters the origdate into the appropriate Juris-M field (so no extra hacks) and then syncs with Zotero?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Juris-M/zotero/issues/16#issuecomment-210665870