[bug] edition field content with number, comma, periods and text gets altered with german locale

edited October 19, 2021
This is a question regarding the "edition" / "Auflage" field and the handling of its data by CSL.

often times we see a macro like this:


<macro name="edition">
<choose>
<if is-numeric="edition">
<group>
<number variable="edition"/>
<text term="edition"/>
</group>
</if>
<else>
<text variable="edition"/>
</else>
</choose>
</macro>


This works fine in most cases, but for the field entry:

4., korr. und akt. Auflage

where I want the content *as is*, the field parsing gets me

4., korr.akt. Auflage because it thinks it is not solely numeric, but messes with the text content.

4, korr. und akt. Auflage here we get 4, korr.akt. AuflageAuflage (with the additional text term).

4. korr. und akt. Auflage => 4. korr. und akt. Auflage, but I would like to have the comma : )

In the CSL 1.0.1 spec is ambiguity with is-numeric it reads:

"Tests whether the given variables (Appendix IV - Variables) contain numeric content. Content is considered numeric if it solely consists of numbers." ... but also with certain other punctuation.

So I am not sure how to get the show-edition-content-as-is without reformulating the input of that field?


thanks

  • edited October 15, 2021
  • edited October 18, 2021
    hi,

    to describe the findings more accurate:

    A)

    the edition field contains:

    4., korr. und akt. Auflage

    (which is the desired output as well)

    B)

    given a csl with the aforementioned macro for edition and a locale "de-DE"

    default-locale="de-DE"

    C)

    the CSL parsing goes into the <else> condition, but messes with the input of the edition field, outputting:

    4., korr.akt. Auflage

    removing und

    This does not happen if default-locale="en", so it looks like some sort of german stopword removing. However, this should not happen for echoing the input of the <text variable="edition"/> as is.

    how and where can this be fixed / issued?

  • // altered the title of this thread
    //
    // perhaps this should be posted somewhere else?
    //
    // thanks : )
  • You are just too impatient. This is fine
  • edited October 26, 2021
    Yeah, so the citation processor is running wild with that field with all sorts of things not working how they should. As you say, e.g., output is also different based on the locale.
    My sense is that it's to accommodate multiple numbers/entries separated by a comma, but it's clearly not right. Zotero is in the process of switching to an entirely different citation processor and the citeproc-js author (i.e. the one responsible for the current one) has had to cut back his work a bit, so honestly I'd work around this for now.
    If you want to post it as an issue, the github issue tracker for citeproc-js is here: https://github.com/Juris-M/citeproc-js

  • thanks @adamsmith,

    as a workaround I use

    <term name="and">und&#8239;</term><!-- (temp) workaround for `und` in edition -->


    in my csl the and is solely used with symbol.

    thank you for your work!
Sign In or Register to comment.