Six months have passed since the last post here. Work on MLZ has been moving forward apace in the meantime, and it’s time for an update on recent changes, of which there have been quite a few. Some of the recent developments are definitely worth writing home about, so we’ll start with those:
- Info Pane Reimplementation
- The original MLZ user interface for the rightmost column was written before I fully understood how the Zotero code worked—and it showed. The behaviour of the creator fields was irregular, tabbing failed in some places, and switching away from a field or the panel would sometimes drop edits in progress. Apart from the annoyance of little bugs, the code itself was difficult to follow, and so hard to maintain. I finally bit the bullet and rewrote it from scratch. It is now more stable, more intuitive, and less of a pain to deal with at the code level.
Both of the field language menus are now presented in a unified right-click popup that behaves the same for creators and ordinary fields (formerly “Change language” for the headline field was a left-click menu on ordinary field labels, and a left-click submenu on creator field labels—if you didn’t notice them there, you are probably not alone). The naming and operation of the menus has also been refined considerably. Here is an overview:
- When MLZ is first installed, the list of variants in the Languages preference panel is empty. In this state, the multilingual menus are suppressed: right-click on a field label does nothing. When languages are added, the menus wake up immediately. This was the original intention, but I’m not positive that it was working (and working smoothly) in recent versions. It is now.
- Field Removal
- Saving a variant field with no content will remove it. This works both for ordinary fields and creators. As in the previous version of the interface, attempts to delete the content of a headline field will be blocked until its variants have all been removed. (Well, you can remove the first or the last name of a two-field headline name, but not both).
- Set Field Language
- “Set Field Language” is the new name for the “Change Language” menu on headline fields. As you would expect, it, um, sets the field language, which shows up as a rollover tooltip. When languages are active, this menu is always available on multilingualize-able fields, even if they are empty (so it is possible to set the language of a field before typing into it).
The menu shows only those choices that make logical sense in the current context. With an empty field language setting, the menu lists only those choices that have not yet been claimed by a variant field. After a field language is set, the menu shows all languages. If an existing variant is chosen, it will be swapped with the headline field together with the field content. To signal the difference in behaviour, variants in use are shown in roman type, and unused choices in italic.
- Change Language
- A “Change Language” menu is available on variant fields. If no language has yet been set on the headline field, the menu will only display if it offers at least two choices (this is meant to prevent gridlock, but I am not sure it’s the right behaviour, and I will be happy to receive complaints and suggestions). Only first-class languages and variants derived from the language of the headline field are shown—so for example, romanized Japanese will not be offered as an option if the headline field is set to English. Variants already claimed by another field are, of course, excluded.
- Add Variant
- The “Add Variant” menu is available only on headline fields. It shows all variants that have not yet been claimed by a subordinate field.
- Jurisdiction Identifiers
- The Jurisdiction field was added to MLZ quite some time ago, loosely based on the draft URN:LEX specification. I have had the good fortune to be supported for membership in the OASIS LegalCiteM working group during the past year, and discussions there drove home to me the importance of a stable, well-ordered set of machine-readable identifiers for courts, in particular—and forced me to realize the flaws in the identifiers I had assigned ad hoc in the existing MLZ implementation. The end result was a push to collect an initial body of information for a workable set of worldwide identifiers in a “Legal Resource Registry” (LRR) now housed on GitHub. The initial data in the LRR draws heavily on work by Michael Lissner of CourtListener at the Free Law Project, and Harry Moers of the World Law Guide at Lexadin.
The identifiers listed in the LRR can be exported in machine-readable form for use in MLZ. This is the new fuel for search-as-you-type menus in the Jurisdiction and (on Case items) the Court field. Apart from providing a more complete and accurate set of identifiers, the user interface performs validation of the Court field against the selected jurisdiction, has a helpful dropdown menu of conforming court names, and allows free-text input for novel courts and edge cases.
The user interface shows only human-readable descriptors in both fields, but the citation processor receives the underlying identifiers in the “jurisdiction” and “authority” fields for use in condition statements. When rendered directly in a citation, the identifiers are converted to human-readable form, and appear as such in the Abbreviation Filter. This gives us the best of both worlds: structured data for the machine, and more accessible descriptions for those of us who are not machines.
Deployment of the new identifier suite was accompanied by a remapping of existing identifiers in user databases. There will have been a few glitches, and many records may show previously recorded court names as “invalid” (with a yellow background), but for the most part things should just work.
- Modular Legal Styles
- Stable jurisdiction identifiers have made it possible to realize a long-standing plan to introduce modular jurisdiction support in the citation processor. Anyone familiar with legal styles generally is painfully aware of the excruciating level of detail required for any single jurisdiction. A glance through the Bluebook shows the degree to which citation conventions vary in ways little and large across jurisdictions. It has been clear for some time that cramming a universal set of legal citation rules into a single CSL style is not viable. The new modular jurisdiction support will make it possible to delegate style development to contributors who are familiar with the requirements of individual jurisdictions, to allow them to work independently, and to draw on their style work across the full suite of CSL styles. This is an exciting prospect that will be the subject of a separate post.
- The Abbreviation Filter Rides Again
As with jurisdiction identifers in MLZ itself, jurisdiction identifiers already recorded in AFZ databases should migrate more or less smoothly to the new human-readable strings. There may be glitches, but most mappings should be accommodated by the upgrade and just continue to work.
AFZ is now accessible, without odd glitches, from the CSL Editor display of MLZ (we can get it working there in official Zotero as well, with a small patch that I hope will be accepted at some point).
- Miscellaneous Small Fixes
- A few things have been fixed or added since the last announcement. Among the highlights of this important if slightly less glamorous list are:
- The addition of “originalDate” and “dateAmended” fields in MLZ, with appropriate mappings to CSL. This change was just banged in because the fields proved necessary for items I was working with.
- A small speedup when dragging items, done by arranging to call the processor just once for the citation and bibliography texts that it stores on the clipboard, rather than twice (a pull request for the fix was accepted for official Zotero as well). Thanks are due to Bruce Rusk of the Department of Asian Studies at University of British Columbia for calling attention to this item.
- An option to suppress trailing punctuation on note styles that include it by default was added to MLZ back in September. This allows the mixture of MLZ-generated footnotes and references inserted directly into discursive footnotes created by the word processor, without modifications to the style—a long-standing need for users of note styles. Thanks for this change are due to feedback from Rónán Kennedy of the National University of Ireland, Galway.
That’s the news. I’m very pleased with the latest round of changes. They navigate us past some very difficult milestones, and open a clear path for future development. With modular legal style support, in particular, I have high hopes community contributions of local style modules. We’ll see how things develop, but the prospects look pretty bright.