Undeclared variables error out about biblatex-csl-converter

[johanneswilm]

Yes, if you refer to a non-declared variable, you'll get an error, and it still parses the rest of the entry. What other way would there be to handle that?

[retorquere]

A non-declared variable isn't actually an error. The below MWE compiles cleanly, but refs2 has variables that are not declared in that same file. BBT parses these and will output them again as variables if you have the appropriate option set.

\documentclass{article}
\usepackage[
    backend=biber,
    natbib=true,
    url=false, 
    doi=true,
    eprint=false
]{biblatex}

\usepackage{filecontents}

\begin{filecontents}{refs1.bib}
@String{pub-FRED = "Freds Publishing"}
@String{pub-FRED:adr = "London, UK"}
\end{filecontents}

\begin{filecontents}{refs2.bib}


@Book{cit1,
  author = {R. A. Bert},
  year = {2000},
  title = {{{Atlantic}} bluefin tuna ({ \emph{Thunnus thynnus}})},
  publisher = pub-FRED,
  address = pub-FRED:adr
}

\end{filecontents}

\addbibresource{refs1.bib}
\addbibresource{refs2.bib}

\begin{document}

\cite{cit1}

\printbibliography

\end{document}

[johanneswilm]

Ah, so you output bibtex that people can use to fill their variables in. Question: Do you have an estimate of how many users worldwide use that functionality? At least to begin with it sounds like a rather complex thing to do to keep variables used in your bibliography separate from your bibliography manager.

[retorquere]

Worldwide? No idea, but it came by user request to me, so at least one, but in fact multiple BBT users structurally have vars in the journaltitle field and use an externally managed var declaration file.

But that's the output side. On the input side, Booktitle = IEEE_J_PROC is simply well-formatted BibLaTeX, even if it may not render a correct reference. But a reference that's missing a title will also render improperly while being cleanly imported.

[johanneswilm]

No idea, but it came by user request to me, so at least one, but in fact multiple BBT users structurally have vars in the journaltitle field and use an externally managed var declaration file.

Ok, that sounds like people who are professional hackers. FW users seem to be less concerned about how to add their own scripting to it all. At least I haven't heard anyone complain about this. If you think it would make sense to add here, maybe this would be code you would want to write?

But a reference that's missing a title will also render improperly while being cleanly imported.

True. But that is because at least so far, we are not enforcing the required_fields list, right?

[retorquere]

Ok, that sounds like people who are professional hackers. FW users seem to be less concerned about how to add their own scripting to it all. At least I haven't heard anyone complain about this. If you think it would make sense to add here, maybe this would be code you would want to write?

There are still a surprisingly large number of BBT users who post-process their references.

But what do you mean with scripting? A separately maintained bibvar file is just standard bib(la)tex functionality. I do have scripting in BBT, but that's only for export, not import.

True. But that is because at least so far, we are not enforcing the required_fields list, right?

So my proposal is then to also not enforce require-var-present 😄 . Simply put, I need the contents of that field one way or the other. I don't mind if it ends up outside the fields section.

[johanneswilm]

But what do you mean with scripting? A separately maintained bibvar file is just standard bib(la)tex functionality. I do have scripting in BBT, but that's only for export, not import.

Users just edit their text, click on print. Done. They don't worry about adding extra files afterwrad.

So my proposal is then to also not enforce require-var-present 😄 . Simply put, I need the contents of that field one way or the other. I don't mind if it ends up outside the fields section.

Maybe what we could do was to add a "raw_fields" that simply contains all the fields in their unprocessed state. and we can also have "other_fields" which contains all fields that were not added to fields that are processed as much as possible.

[retorquere]

Assuming the raw fields would have had stuff like \"o already transformed, that would be the ideal option for me.

[johanneswilm]

The raw fields do have those transformed. However there are likely shortcomings in our translation table.

[retorquere]

I'll not be using the raw fields as I need the cooked values.

[johanneswilm]

Ok, the raw fields represent no overhead to us. Until now their values were simply overwritten for a small list of fields that were handled differently, so the original field values were simply overwritten by reformed versions. Now we handle all the known fields according to specific rules, so it was just a matter of cleanliness not to overwrite the values. But yes, you'll probably want the unknown and unexpected values.

[retorquere]

I'll just use those first. Object.assign FTW.

[retorquere]

bare variables give only { type: 'variable_error' } as error? no reference?

[retorquere]

and field? Or is that not available?

[retorquere]

What is the difference between variable_error and undeclared_variable?