Citation style bug with report number

JoshCraig

Since upgrading my Zotero Standalone to 4.0.29.10 I'm having problems with a macro I use on the report number field.

I have a text macro 'issue' which is supposed to add in "no. " (no. with a non-breaking space) when only a numeric value is entered into the report number field.

It used to work fine, but since updating it's behaving strangely.

If I enter 1234 in the report number field I now get '1234' back instead of 'no. 1234'.

If I enter 'no. 1234' I get back 'no. 1234' without the non-breaking space.

If I enter 'Cat. no. 1234' I get back 'Cat. no.  1234'. (So a breaking and non-breaking space. This is a format I need regularly.)

If enter 'Cat. no. 1234.0' I get back 'Cat. 1234.0' (The 'no.' just disappears.)

Any thoughts?

Here's the code:

https://gist.github.com/JoshCraig/46f07e0aa0534bb9a60b7a4310f856b1

fbennett

Those combinations all seem to work fine now, testing with the latest processor release. Try installing one of the Propachi plugins. The plugin will slot the latest processor version into Zotero: if it works, you can run with it, but be sure to remove it at the next Zotero release.

If you still get bad output with the latest processor, let us know.

JoshCraig

How do I install the plugin if I'm not using Firefox?

JoshCraig

OK I think I did it right...
Tools>Add ons>Install Add on from file

But I don't see any change to my references (even after refreshing and swapping back and forward between citation styles).

fbennett

I'll keep an eye on the issue, but I'll need to reproduce it in order to fix it.

JoshCraig

For me it comes up any time I use a Report item and have 'Cat. no. XXXX.0' using my citation style.

For the record, the subsequent-author-substitute issue I was just posting about (https://forums.zotero.org/discussion/62292/subsequent-author-substitute-not-working-for-single-field-authors#latest) also doesn't seem to be fixed with the Propachi plugin.

JoshCraig

'Cat. no. XXXX.0' in the Report Number field that is.

fbennett

I don't doubt your report; but I can't address an issue that I can't reproduce.

It is possible that the Propachi plugin does not take effect correctly in Standalone. If you have Firefox installed, you could test to see if the Propachi plugin fixes your references in Zotero for Firefox (after stopping Standalone). If it does the trick, you could use that for the present, while waiting for a fresh official release of Standalone.

JoshCraig

Sorry, I'm afraid I don't have Firefox and can't easily install it on a work computer.

fbennett

We'll have to wait for someone else to do some testing then. @adamsmith? @Rintze? Others?

adamsmith

Report number isn't issue but number
http://aurimasv.github.io/z2csl/typeMap.xml#map-report
works with that corrected (and the other call of the number variable, which is why this is getting rendered at all, removed)

JoshCraig

OK right. It did used to work though.

Sorry for my ignorance, but which bit do I need to change?

adamsmith

I don't know the details of the style, but you'll have to switch issue for number in the macro (though only in the variable, not the term). If you also need the issue variable rendered by the same macro, you'll have to add both there (I don't think there's an item type that has both, so just adding them one after the other is probably fine)

JoshCraig

OK the variable, not the term. Got it.

JoshCraig

Thanks for your help.

fbennett

(Thanks for the assist @adamsmith)

JoshCraig

I can't quite figure out how to fix this though.

I've completely deleted the macro and just tried using
and in the bibliography.

In both cases, if I have 'Cat. no. 1234.0' in the Report Number field it returns:

'Cat. 1234.0'

Is this what I should expect to see??

JoshCraig

i meant I've just tried using:

text variable="number"

and

number variable="number"

adamsmith

ok, that I can replicate -- @fbennett any idea why citeproc would suppress the no. with 12345.0 but not with 12345 at the end of the string?

JoshCraig

I'm sure it didn't used to...

adamsmith

oh, it also shouldn't (and hopefully won't, soon).

JoshCraig

For me, both text variable="number" and number variable="number" suppress the 'no.' regardless of whether i have 12345.0 or just 12345.

Also might be worth noting that 'no.' doesn't get suppressed if it's sentence case 'No.'

JoshCraig

Getting trickier...

Cat. no. 12345.0 deletes 'no.'

Cat. no. 12345 keeps 'no.'

no. 12345 gets rid of 'no.'

no. 12345.0 gets rid of 'no.'

fbennett

I'm not sure what the code being tested looks like anymore, but I've learned something from a little poking around.

Most of the weirdness here is caused by an internal list of short-codes in the processor that includes "number," on the assumption that the CSL locale will follow the CSL schema, which does specify a "number" term.

Unfortunately, the CSL locales do not provide any value for a "number" term.

So when the processor attempts to access the missing term, it turns up empty, and you get no label at all. For an immediate fix, define the "number" term in the style's own locale. That should not cause a validation error, since the term is in the grammar specification for CSL 1.0.1.

When the label is included or not depending on an "is-numeric" test, things should then work normally, with one exception. The input "Cat. no. 1234.0" evaluates as "non-numeric" (and so omits the label, in the conditional code I have tested with here). There is a bug that causes it to throw out the "no." manually entered in the field: that is not right, and I will look into it as soon as I get a chance. Everything else seems to be in order.

fbennett

(I suppose that what should happen is that the short-codes, which are not part of the CSL specification anyway, should be treated as dumb strings if they are not defined in the locale. Live and learn.)

adamsmith

The input "Cat. no. 1234.0" evaluates as "non-numeric" (and so omits the label, in the conditional code I have tested with here). There is a bug that causes it to throw out the "no." manually entered in the field: that is not right, and I will look into it as soon as I get a chance. Everything else seems to be in order.

yes, that's the problem I'm seeing exactly.

fbennett

This bug should now be fixed, in citeproc-js tagged release 1.1.130. I have pushed the new code into the Propachi plugins, so you can reinstall one of those to see if the processor now behaves itself.

Thanks to the ambition of my bad-boy extensions to numeric variable processing, this was a little tricky; but I think the fixes have put things back in order. There were two problems:

• A mid-field short-code label before a non-numeric element (as in "Cat. no. 1234.0") was being swallowed.
• The "no." short-code inside a field is mapped to the "issue" variable, and that promised to become a source of further confusion.

The fixes prevent loss of short-code labels that come before or after a non-numeric element by treating the short-code and the elements before and after it as literal text.

When rendering labels on numeric elements for the "number" variable only, the processor will use a "number" term if available, falling back otherwise to the "issue" term. (No style defines a "number" term at present, but if a need arises to define the two terms separately, things should work as expected.)

Apologies for the inconvenience, and thanks to everyone for pinning this issue down.