# \mkbibquote does not close quotation marks if immediately followed by colon

The following biblatex record (embedded within a minimal LaTeX example):

\begin{filecontents*}{\jobname.bib}
@article{test1,
Author = {Craft, Robert},
Title = {Stravinsky at His \mkbibquote{Bird-Best}: Robert Craft Untangles the Tales Surrounding the Creation of \foreignlanguage{french}{\mkbibemph{Le rossignol}}},
Journaltitle = {Opera News},
Date = {1982},
Volume = {46},
Number = {8},
Pages = {14-15, 34}
}
\end{filecontents*}
\documentclass{article}
\usepackage[autostyle=true, english=american, french=guillemets, german=guillemets]{csquotes}
\usepackage[french, german, american]{babel}
\usepackage{biblatex}
\begin{document}
\cite{test1}
\printbibliography
\end{document}


is incorrectly rendered by pdflatex as:

Robert Craft, “Stravinsky at His ‘Bird-Best: Robert Craft Untangles the Tales Surrounding the Creation of Le rossignol,’” Opera News, 1982, no. 8, 14–15, 34.

Note that the closing quotation mark after Bird-Best is missing.

With lualatex, however, there is no such issue. The reference is formatted correctly:

Robert Craft, “Stravinsky at His ‘Bird-Best’: Robert Craft Untangles the Tales Surrounding the Creation of Le rossignol,” Opera News, 1982, no. 8, 14–15, 34.

I have tried all the latest stable and development branches of biblatex, including 2.9a and 3.0. The issue is likely related to csquotes?

PLK, biblatex author, and I have already discussed this on GitHub (https://github.com/plk/biblatex/issues/259), but we have so far been unable to track down the cause.

• Welcome to TeX.SX! Usually, we don't put a greeting or a “thank you” in our posts. While this might seem strange at first, it is not a sign of lack of politeness, but rather part of our trying to keep everything very concise. Accepting and upvoting answers is the preferred way here to say “thank you” to users who helped you. – Martin Schröder Sep 28 '14 at 13:21
• Confirming that the patch posted by @JosephWright at the github link above resolves the issue. – BorromeanNot Sep 28 '14 at 23:19

In the case outlined biblatex uses a macro called \blx@usqcheck which it uses for US-style quotations with 'moving' punctuation. This checks ahead for punctuation, spaces and so on but also includes a check:

\if\noexpand\@let@token\relax
\blx@usqcheck@i\blx@tempb
\fi


where the \blx@usqcheck@i\blx@tempb does not insert any closing quote mark but saves if for future use. (There are a couple of internal branches sharing the above code, hence it not be immediately obvious.)

The original author of biblatex leaves us no notes as to what this code was meant to do, but I think he was aiming to allow an explicit \relax to be used to prevent moving punctuation

\mkbibquote{some odd text}\relax ,


The problem is that the construct \if\noexpand\foo\relax is true if \foo is a macro at all, not just if it is equal in meaning to \relax. (The \noexpand primitive makes \foo temporarily equal to \relax if it is a macro but not if say you've done \let\foo=a.)

That leads us to the problem. When pdfTeX is in use and the french option has been given for babel, the character : is 'active' and has a macro definition even if the active language is not French. Thus the test in biblatex goes the 'wrong way': it finds a macro following the quote, thinks this is a relax and skips the closing punctuation. That doesn't happen with LuaTeX as it doesn't use an active : for French typography, so the issue never shows up.

The fix I've suggested is to add a second test in the right place: as a short patch

\makeatletter
\def\blx@usqcheck#1#2{%
\def\blx@tempa{#1}%
\def\blx@tempb{#2}%
\ifx\@let@token\space
\blx@usqcheck@i\blx@tempa
\fi
\ifx\@let@token\@sptoken
\blx@usqcheck@i\blx@tempa
\fi
\if\noexpand\@let@token\relax
\ifx\relax\@let@token
\blx@usqcheck@i\blx@tempb
\fi
\fi
\expandafter\blx@usqcheck@ii\blx@quotepunct\relax&}

\def\blx@usqcheck@i#1#2&{\fi#1}
\makeatother


This now checks that the meaning of the following macro starts with \relax. There are still cases that might go wrong, but for the moment this seems like the 'lowest risk' fix. As I say, what is lacking is a note on why this test is there: it's not immediately obvious what the reasoning is!

• This is now implemented in the 3.0 dev version. – PLK Sep 29 '14 at 11:17