MS Word. Manually entered abbreviations aren't preserved between Word and JurisM restarts #43
Comments
JohnLukeBentley
changed the title
|
Thank you for checking so carefully. This reveals a couple of bugs. I'll need to dig into it a little further, but here is what I've determined so far. A direct inspection of the database shows that the abbreviation is actually being saved to the database when you apply the initial abbreviation. The problem is that when the document is reopened, this portion of the abbreviation data (the "raw" form of jurisdiction identifers) is being loaded incorrectly, with the result that it is not displayed among the abbreviation choices. The "raw" key (the second column in the abbreviation listing under Places) provides a hint to the fault. Following your example steps, all three of the options for "New South Wales" show as "australia". This should not be so. I believe that the key used internally is something like "AU|New South Wales." So (by hypothesis only, so far) if the key is correctly read (and displayed), the saved abbreviation should be available after a restart. More news on this later. I'll take a look at it today or tomorrow. |
|
Thanks for that. That's very good news that it might reveal a couple of bugs. At this stage, being the newbie, I've found this abbreviation mechanism both awesome (in the ambition to facilitate both a standardization and user flexibility to overrule the standardization) and confusing. The confusion is in part due to my having simply to conceptually catch on to what's going on here ... but sorting out those bugs might mean that the correct entries presented to me will be less confusing. Good luck with the debugging! |
|
There is plenty of scope for making abbrevs easier for users to understand and control. That's beyond my skill set, but others will pitch in over time, if the project persists long enough. I've figured out one further thing about your sample. If a "Place" abbreviation is applied to a top-level country name among the jurisdictions (i.e. if you set the statute to "Australia" as the jurisdiction), the abbreviation will stick. That brings us closer to understanding the fault in the code. As background, the jurisdiction field is stored behind the scenes as a code. Australia is "au", and New South Wales is "au:nsw". The fact that we're seeing "australia" in the listing means that "au:nsw" (which would display as "au|new south wales") is being stripped to "au" (which displays as "australia"). There are some low-level issues here that I need to think about more carefully. My initial feeling, looking at the fault and the data, is that the abbreviations database should be using the same key internally and externally as the citation data itself does internally and externally (so in your example, both should have "au:nsw" as their internal record, and "AU|New South Wales" as their displayed field value). That will make the data structures easier to follow, and allow arbitrary changes (to fix spelling and script errors in the displayed values) without breaking things. Fixing this could affect the abbreviation behavior in existing documents that are live in the field, but it needs to be fixed, and now is a better time than later. |
|
I've added https://www.courtlistener.com/opinion/107965/brandenburg-v-ohio/ to my example above as another Entry in JurisM and another citation in my document. That is, to have the US Jurisdiction kicking around. In {MS Word} > .... > "Manage Abbreviation LIsts" I now see, with the manual addition of the "NSW" string and the inclusion of made up column names ...
Yes, that make sense to describe what I'm seeing. Given my made up column names I take it by ...
... you mean something like ...
That is, I take it you mean that the third data row should really display as
or, if you have made an alternative design choice,
On UI changes (and perhaps this should be posted as a separate issue) ...
Well it sounds like those couple of grad students, with that bit funding behind them, will have a good opportunity for an overhaul here. But, short of the overhaul, there's relatively simple improvements that could be made, if my understanding of what's going in is correct. Perhaps ...
I'm a bit out to sea on the role of "default" rows. I see, in the JurisM standalone, a default checkbox, which presumably triggers (when ticked) the "default" row in the Abbreviations List. But I'm not seeing the use case for this. ... ... and the default button and default row abbreviation list interaction might have bug in it ...
|
Yes, that's right.
Yes. I'd be every happy to accept a pull request if someone stepped up to make that happen.
I won't be asking them to touch Juris-M itself, unless they have an interest, and finish the work on jurisdiction codes early. The internals of Zotero/Juris-M have a steep and unforgiving learning curve, and don't lend themselves to short-term commitment, unfortunately.
Not all references that apply abbreviations are legal references, so "default" is needed. That said, for items that to have a jurisdiction value, "default" could be dropped, that's true. I'm not at all happy with the abbreviation editing lists as they stand, but it will take awhile before we step into improving usability. Lots of potential potholes there.
No, that's correct. It's using the abbreviation with least distance from the jurisdiction of the item. "default" is an ultimate fallback. |
I'll keep this as it stands, at least for the present. Colon works as an unambiguous delimiter in jurisdiction codes, because it's not permitted inside the elements, so the display form can be changed arbitrarily at some point down the road, so long as the underlying code is use for processing. Vertical-bar is already used as a separator between the elements of institutional names, where it's needed because the content there is free-form text. Even if it's off-putting on first encounter, I think the barrier to getting used to it is pretty low. |
|
Thanks. On separators. I'll just note your (reasoned) preferences on it and be silent on that topic for now. On the abbrev button, as a ladder for someone to step up to moving it, I've opened #45. On defaults ... ... I am seeing, thanks to your explanation, a default "ultimate fallback" in my non-legal Journal Article entry ... Hwang, J., and K. Lee. 2014. “Determination of Outdoor Tobacco Smoke Exposure by Distance From a Smoking Source.” Nicotine & Tobacco Research 16 (4), April: 478–484. doi:https://doi.org/10.1093/ntr/ntt178. ... That is, in Word's "Manage Abbreviation List" > Title ... I see against a "default" only that title. I have remaining confusions about defaults. But I think it would be better if I held off for now asking you about it, because we might be able to more productively exploit my ignorance on it, and some other JurisM aspects (in a manner that I won't specify here and now). So, to summarize where we are at with this thread, there just remains the original set of bugs which you've approximately situated in the second post. |
|
I believe that abbrevs are associated with the CSL style, not with the
document.
On Sun, Mar 18, 2018, 22:12 John Luke Bentley ***@***.***> wrote:
Thanks.
On separators. I'll just note your (reasoned) preferences on it and be
silent on that topic for now.
On the abbrev button, as a ladder for someone to step up to moving it,
I've opened #45 <#45>.
On defaults ...
... I am seeing, thanks to your explanation, a default "ultimate fallback"
in my non-legal Journal Article entry ...
Hwang, J., and K. Lee. 2014. “Determination of Outdoor Tobacco Smoke
Exposure by Distance From a Smoking Source.” Nicotine & Tobacco Research 16
(4), April: 478–484. doi:https://doi.org/10.1093/ntr/ntt178.
... That is, in Word's "Manage Abbreviation List" > Title ... I see
against a "default" only that title.
default determination of outdoor tobacco smoke exposure by distance from a smoking source
default R v Ahmad Alameddine; R v Lee McArthur [2018] NSWDC 43
Australia|AU R v Ahmad Alameddine; R v Lee McArthur [2018] NSWDC 43
...
I have remaining confusions about defaults. But I think it would be better
if I held off for now asking you about it, because we might be able to more
productively exploit my ignorance on it, and some other JurisM aspects (in
a manner that I won't specify here and now).
So, to summarize where we are at with this thread, there just remains the
original set of bugs which you've approximately situated in the second post.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#43 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACsluTbevc9jnUufHkavm79AtjI55n-ks5tfzA9gaJpZM4Surt0>
.
|
|
Yes, that's right. I think the point there is just that the button opens a document-wide list of potential abbreviations, rather than one limited to the context of the citation carrying the button. |
@KarlHegbloom and @fbennett, that changes my view of what's going on. The "Manage Abbreviations List" does have a prominent "Style" group, within which is listed the current Style. But it also seems to be that the elements under "Lists" come from the set of citations/references that have so far been given in the document. So would it not be more accurate to say that "Manage Abbreviation Lists" (when working as intended) stores abbreviations for the intersection of a style and a document? |
|
Yes, that would be an accurate description. |
|
But those stored abbrevs are expected to persist, both for this document,
and for future ones, so you'll have consistent abbrevs, and not have to
enter them again.
On Tue, Mar 20, 2018, 22:42 Frank Bennett ***@***.***> wrote:
Yes, that would be an accurate description.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACslg1MEjkugGnlPeLkzu7QLIqpedOHks5tgdodgaJpZM4Surt0>
.
|
|
In the quick citation dialog, you can enter ibid to have the search
narrowed to the ones already cited in you're document.
On Wed, Mar 21, 2018, 18:20 Karl Hegbloom ***@***.***> wrote:
But those stored abbrevs are expected to persist, both for this
document, and for future ones, so you'll have consistent abbrevs, and not
have to enter them again.
On Tue, Mar 20, 2018, 22:42 Frank Bennett ***@***.***>
wrote:
> Yes, that would be an accurate description.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#43 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AACslg1MEjkugGnlPeLkzu7QLIqpedOHks5tgdodgaJpZM4Surt0>
> .
>
--
***@***.***
|
|
@fbennett. I've updated to 5.0.39m13. It looks like you've taken care of those Word Plug-in Abbreviation List bugs:
An additional bug I've come across, which may or may not be related to the current set, is that the (hidden code?) jurisdiction code "us" comes through, whether you suppress the United States Jurisdiction or not. To reproduce:
I get
I expect
Go back in the Abbreviation List and suppress the United States|US jurisdiction. I get
... in short, and to repeat, there's a rogue "us" code coming through. By contrast this isn't appearing as a problem with my citations having Australia|NSW jurisdiction. |
|
Those steps reveal a bug, in that I am unable to complete them, at least under Linux. Saves from CourtListener currently fail with a warning, and fall back to the Web Page type. Web Page has no "jurisdiction" field, and due to a coding error in 5.0.39m13, the item type can't be changed to anything else. Possibly your system acquired a cookie from an earlier version that enables the CourtListener translator -- I will restore the functionality in the next release. On the country codes, that's a bug, but I get different behavior here, and United States and Australia behave in exactly the same way. In the full form, I get "United States us", and "Australia au." With suppression I get "us" and "au". The cause is in a coding error that fails to suppress the jurisdiction, and passes through the raw code value, when a top-level national jurisdiction is selected. I will fix that and make a fresh release in the afternoon. Thanks for reporting that! |
Sorry, I had an exiting Brandenburg v. Ohio entry that I had previously imported (in an earlier version) from CourtListener and probably changed from Web Type to Case type. So if you are seeing new strange importing behaviour then I'll probably have that behaviour too (without attempting the reproduction). In short, it sounds like you've correctly identified the bugs I'll have at my end. Thanks for the prior and future fixes! |
|
The abbreviation failures and the CourtListener translator is properly enabled in v5.0.39m14. Lots of bugs fixed in this release -- thanks for reporting these issues! |
|
On 5.0.39m15 all these bugs look fixed at my end. Great work! |
On JurisM 5.0.37m10
To reproduce:
Fetch and insert a particular legal citation (an Australian, New South Wales, Statue):
... all fine so far. Let's change the "Australia" Jurisdiction to the regionally specific "NSW" abbreviation ...
... all fine so far, let's restart ...
... and if we go back into the "Manage Abbreviation Lists" the previously manually entered abbreviation is lost.
Looks like either a bug or I'm misunderstanding how the operation should be done.
If I am misunderstanding how the operation should be done then that might betray that the UI/workflow has room for improvement.
The text was updated successfully, but these errors were encountered: