As readers of these very occasional notes will have noticed, the promised book on Multilingual Zotero has not yet hit the shelves. The proof copies were delivered back in October, but I am a full-time teaching academic, and I was not able to get to the final edits during term time. We are now in holiday, and … the hiatus has given rise to a spate of inspiration that promises to push the book release back by a few more weeks.
Documenting your software can be a humbling experience. Although MLZ was feature complete and stable and all those good things, two sections of the book bothered me. In the time since the manuscript was “finished”, it has become clear that they bother others as well; and as we slid into the holidays, I decided to do something about both.
One quibble was with the menu hacked into the Extra field. Several people picking up MLZ in our faculty and elsewhere have been tripped up over a missing jurisdiction value on legal item types. It is crucial to include jurisdiction information on any primary legal reference record, and the awkwardness of the interface for entering it was clearly going to be a problem. This was just the tip of the iceberg, actually: the MLZ styles rely on an assortment of fields that are not available in official Zotero, some of them quite nearly as important as jurisdiction itself.
The second issue was the lack of multilingual sync. A multilingual reference manager really comes into its own when records can be smoothly shared across national boundaries. Shared records with rich metadata lower the barriers to collaboration. This is where the real value is. Nonetheless I had steered clear of implementing multilingual sync, partly to keep my life simple, and partly out of a concern for database-level compatibility with official Zotero.
A third issue crept into the mix as I was fretting over the two problems above. Several users have been confused by the differing citation results produced by official Zotero and Multilingual Zotero when using the same CSL style. I realized that this was actually a side-effect of scrupulously maintaining database-level compatibility with the official client: either tool can be used against the same database, and many users seemed to be doing just that, because Standalone is cool and there is no Standalone version of MLZ (yet). The resulting confusion promised to make debugging of styles more difficult, and reflect badly on CSL and Zotero to boot.
So I laid a plan to address these niggles, which is now about 80% complete — hence this note. The changes are much simpler to explain than the forces that drove me to produce them. Here’s a short list:
- The item panels for the legal types will be cleaned up, and several essential fields will be added. A new Jurisdiction field will become available, which always carries a value and is accessible only via a controlled list. The default will be configurable at two levels: a temporary default for cross-border and international work; and a persistent fallback value set initially to the US jurisdiction. The funky menu on the Extra field will go away.
- Multilingual sync will work, without any special setup. Items with multilingual variant and non-Zotero fields in them will carry that data in the Extra field for sync purposes only. On the client side, this will be completely transparent; but you will notice the data as computerspeak gibberish prefixed to the Extra field in the online version of your libraries and groups. It will likewise be visible in-the-raw in any official Zotero client that syncs the data. You can (and should) just leave it there.
- For better compatibility between the MLZ legal styles and the styles in the official CSL repository, I will be reversing an early decision to map Date Decided and other primary date fields of legal item types to the original-date field. This seemed right semantically, but it has caused no end of frustration, even among the patient community of early adopters. We will be reverting the “primary” date to issued everywhere, and a new publication-date field will be introduced to cover cases (pun intended) in which the decision date and the publication date differ.
- The database upgrade needed to support these changes will break compatibility with official Zotero at the database level. It will still be possible to sync MLZ data to an official Zotero client; the only constraint is that the two systems be set up to use separate databases. That requirement of a conscious user decision will reduce the threat of confusion that had been brewing.
These are substantial changes, and there will be an impact on user data. Apart from the loss of database-level compatibility with official Zotero, some or all data formerly stored in the Extra field with the old menu hack may need to be reentered manually. I am not yet sure how aggressive I should be about supporting automatic migration. If this is a serious issue for you (and if you have read this far!) please let me know.
That’s all the news for now. Back to work, more soon when I have something to show …