Impossible parallel citation

[georgd]

The new 5.0.90m7-beta.17 creates a parallel citation between a ECJ case and an AT OGH case. No element appears to be dropped at first glance but the parallel-delimiter-override is active:

That’s probably not new, rather I haven’t tested this combination before. I can’t actually test the processor because of another bug.

[fbennett]

Can you post the CSL JSON of the items? Not sure where the citation breaks are, or which fields the values come from.

[georgd]

I prepared a test here, containing the first two items: https://github.com/georgd/jm-style-tests/commit/fae60a70d4b3a9e032bd2c11b3b686c99e2653ab

[fbennett]

I can't reproduce the fault with the test. I tried adding a third item, but I still get a semi-colon delimiter everywhere. The test-runner bug affecting multiple items has been fixed, so you can run the test there. Can you make it fail in the test runner?

[georgd]

I can’t either. I added all items I have in the Word file and still the test passes.

[georgd]

Here’s the original export from Juris-M

[
    {
        "id": "2012",
        "type": "legal_case",
        "multi": {
            "main": {},
            "_keys": {}
        },
        "abstract": "Court composition in Case Type\n\njurism",
        "authority": "ogh",
        "genre": "verst Senat",
        "number": "6 Ob 24/11i",
        "jurisdiction": "at",
        "issued": {
            "date-parts": [
                [
                    "2012",
                    9,
                    11
                ]
            ]
        }
    },
    {
        "id": "wilhelm1998a",
        "type": "legal_case",
        "multi": {
            "main": {},
            "_keys": {}
        },
        "abstract": "AT Case with parallel cites",
        "authority": "ogh",
        "container-title": "ecolex",
        "number": "2 Ob 328/97t",
        "page": "692",
        "jurisdiction": "at",
        "commenter": [
            {
                "literal": "Wilhelm",
                "multi": {
                    "_key": {}
                }
            }
        ],
        "issued": {
            "date-parts": [
                [
                    "1998",
                    2,
                    12
                ]
            ]
        },
        "publication-date": {
            "date-parts": [
                [
                    "1998"
                ]
            ]
        }
    },
    {
        "id": "MoreKLM2012a",
        "type": "legal_case",
        "multi": {
            "main": {},
            "_keys": {}
        },
        "abstract": "EuGH",
        "authority": "ecj",
        "number": "Rs C-139/11",
        "title": "Moré/KLM",
        "jurisdiction": "eu.int:cjeu",
        "issued": {
            "date-parts": [
                [
                    "2012",
                    11,
                    22
                ]
            ]
        }
    },
    {
        "id": "2018",
        "type": "legal_case",
        "multi": {
            "main": {},
            "_keys": {}
        },
        "authority": "lg",
        "note": "DOI: ECLI:AT:LG00929:2018:RFE0100040",
        "number": "2R247/18s",
        "jurisdiction": "at:innsbruck:feldkirch",
        "issued": {
            "literal": "29.11.2018",
            "date-parts": [
                [],
                []
            ]
        }
    }
]

[georgd]

I don’t know if this could help: I copied them over to a group library: https://www.zotero.org/groups/2589306/jm-issues

[fbennett]

Gettting sleepy here, so I'll need to stop for the evening---but I've reproduced it in a test! I imported the items into Jurism (ha, discovering a client import bug in the process), then dumped the input seen by the processor. Copying the exact item data input seen by the processor into INPUT finally caused the bug to emerge. So it's something in the input that's triggering this. Tomorrow we'll track down the exact cause.

Off the top of my head, though, I'd guess that the processor is identifying parallels by looking at the item data, rather than what actually gets rendered. So there is probably a no-repeat variable in there somehow that doesn't get rendered, but nonetheless triggers the delimiter.

That's the theory, tomorrow we'll test it!

[fbennett]

(Ah, it's the "seeAlso" array that every item carries. It's empty on both items, but if it's removed, the delimiter comes out right. If that holds up against inspection tomorrow, it's a bug, and should be easy to fix.)

[georgd]

This isn’t reproducible any more with 5.0.90m7-beta.19

[fbennett]

Yay. How are we looking for a release? (Third time asking is the charm? :)

[georgd]

Yes, thanks a lot! I think, it looks good for a release now :)

[fbennett]

(eagerly springs into action)