[citeproc-bug] punctuation in quote failing
I promise this is no attempt to subvert
https://twitter.com/fgbjr/status/404052546781585408
but:
Sample data and style:
https://gist.github.com/adam3smith/7621211
Expected citations:
Daniel W. Drezner, “An Open Letter to the New York Times Concerning Thomas Friedman,” January 23, 2013, accessed August 24, 2013, http://drezner.foreignpolicy.com/posts/2013/01/22/an_open_letter_to_the_new_york_times_concerning_thomas_friedman.
actual citation:
Daniel W. Drezner, “An Open Letter to the New York Times Concerning Thomas Friedman”, January 23, 2013, accessed August 24, 2013, http://drezner.foreignpolicy.com/posts/2013/01/22/an_open_letter_to_the_new_york_times_concerning_thomas_friedman.
(note the position of the comma in vs. outside the quotation mark).
I realize that the coding could be cleaner, but there aren't that many nested features here, so this really should work. I'm about to fix the Turabian style otherwise, so this won't affect that style anymore, but it should still work.
https://twitter.com/fgbjr/status/404052546781585408
but:
Sample data and style:
https://gist.github.com/adam3smith/7621211
Expected citations:
Daniel W. Drezner, “An Open Letter to the New York Times Concerning Thomas Friedman,” January 23, 2013, accessed August 24, 2013, http://drezner.foreignpolicy.com/posts/2013/01/22/an_open_letter_to_the_new_york_times_concerning_thomas_friedman.
actual citation:
Daniel W. Drezner, “An Open Letter to the New York Times Concerning Thomas Friedman”, January 23, 2013, accessed August 24, 2013, http://drezner.foreignpolicy.com/posts/2013/01/22/an_open_letter_to_the_new_york_times_concerning_thomas_friedman.
(note the position of the comma in vs. outside the quotation mark).
I realize that the coding could be cleaner, but there aren't that many nested features here, so this really should work. I'm about to fix the Turabian style otherwise, so this won't affect that style anymore, but it should still work.
The style is setting the comma as a prefix buried in a macro. To the processor, the internal structure looks something like this (very roughly): In order to respect punctuation-in-quote against that sort of structure (to arbitrary depth), the processor would need to do the following for every affix in the output object:
- Confirm that content exists on the local node;
- For each successive layer to the top of the object:
- Check whether a blocking partner exists on the higher-level partner (i.e. a sibling suffix against a prefix, or a sibling prefix against a suffix);
- Check whether the higher-level partner requests quotes;
- Check whether the higher-level partner has content;
- Remove the punctuation from below and add it to the higher-level partner's affix or field content as appropriate.
While the processor does do some of this tree-trawling to control for duplicate spaces and punctuation, this would be pushing things pretty hard. It can legitimately be called a bug, I suppose, since the specification prescription is general, but I think I'll pass on trying to get the processor to handle it.Should the style be based upon the user's computer language setting, the language tag of the article or, perhaps, the journal publication place? How might this affect the many users of non-English languages.
'punctuation-in-quote' is a locale setting. It's false for most languages, true for US English.
I really don't think there is a conceptual problem here - it has certainly never come up as one. This is solely a coding issue.
Basically this means that we cannot use any punctuation marks in affixes within macros for styles that include quotes.
That seems like a pretty major restriction on coding to me, which will make any such style hugely more complex - adding about twice the number of macros. We'd have to do for every single style with quotes something along the lines of your re-write for Chicago (the group nesting is a separate issue, but we would need all the different macros even without it).
I'm quite concerned that this may mean many, many hundreds, if not thousands of lines of non-automatable style-rewrites to get around this reliably.
There is really no way we can get this working in the processor with less effort? Post-processing maybe?