biblatex: both `langid` and `language` are needed?
I use BetterBiBTeX and find that `langid` doesn't "work". In the reference list generated by `biblatex`, we need a comment like "[in Japanese]", but this functionality is activated only when `language = {japanese}` is included in the bib entry. `langid` doesn't do this. I'm pasting a self-contained example below.
In several past threads in this forum, it seems to have been concluded that `langid` is the bibtex field for the Zotero field `language` to be mapped to. But, given the fact that the actual `biblatex` doesn't do the correct job with `langid`, shouldn't both `langid` and `language` be generated for the bibtex file?
(By the way, what's the proper method to display a block of code in this forum? By trial and error, I've found
In several past threads in this forum, it seems to have been concluded that `langid` is the bibtex field for the Zotero field `language` to be mapped to. But, given the fact that the actual `biblatex` doesn't do the correct job with `langid`, shouldn't both `langid` and `language` be generated for the bibtex file?
\documentclass{article}
\begin{filecontents}[overwrite]{tmp.bib}
@article{UseLanguage,
title = {Title of UseLanguage},
author = {A. U. Thor Language},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
language = {japanese}
}
@article{UseLangid,
title = {Title of UseLangid},
author = {A. U. Thor Langid},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
langid = {japanese}
}
@article{UseLangidAbbrev,
title = {Title of UseLangidAbbrev},
author = {A. U. Thor LangidAbbrev},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
langid = {ja}
}
\end{filecontents}
\usepackage[sorting=none]{biblatex-chicago}
%\usepackage[sorting=none]{biblatex}
\addbibresource{tmp.bib}
\begin{document}
\nocite{*}
\printbibliography
\end{document}
(By the way, what's the proper method to display a block of code in this forum? By trial and error, I've found
<blockcode>
kind of works, but it doesn't treat the block as a code. For example, it highlights only @article
. The above code is pasted with the <code>
tag, which is better but with the same highlighting problem.)
language
gives the bibliographic information in which language the work is written.langid
, on the other hand, tells babel or polyglossia which language to switch to for typesetting the entry.I know that. My point is: Generate **both** `langid = {japanese}` and `language = {japanese}` in the bibtex file from the **single** `language = japanese` field of Zotero.
According to the biblatex manual, there is no field
language
, justlangid
/langidopts
.language
a bibtex field (or more specifically, a babelbib field). If you have a biblatex style that needslanguage
, I can take a look at that.biblatex-chicago
considers itself the standard biblatex, and that does have alanguage
field edit: instead of thelangid
field apparently. Swell.\DeclareSourcemap{
\maps[datatype=bibtex]{
\map{
\step[fieldsource=langid,fieldtarget=language]
}
}
}
language
is a biblatex field, listed on p. 23 of the current version of the biblatex manual and listed as optional field in most entry types.https://retorque.re/zotero-better-bibtex/installation/preferences/export/index.html#export-language-as
Now, would there be any harm if "export-language-as" were set to "both" by default?
Actually, that was the reason why I posted here instead of posting to the BBT github: in order for other users to learn from the discussion.
Zotero's "language" field should be exported to the biblatex field "langid" only. Both fields are supposed to contain only language tags that control formatting, e.g. capitalization of titles and hyphenation.
Biblatex's "language" field, by contrast, which has no equivalent in Zotero, is used to generate textual output in a formatted bibliography.
Exporting Zotero's "language" field to the biblatex field "language" would result in what are now merely language-dependent formatting instructions all of a sudden turned into textual output as well, breaking virtually every style on the biblatex side.
The OP might have noticed that Zotero itself never generates textual output from its own "language" field, so I do not think the expectation that this field can be used sensibly to populate biblatex's "language" field (which, again, serves a very different purpose) is justified at all.
Information to be stored in a Zotero database and then exported to the "language" fields of biblatex must therefore be stored elsewhere, just not in the "language" field of Zotero.
tex.language
entry inextra
-- or by setting BBT's language-field handling to the non-default "both".> Exporting Zotero's "language" field to the biblatex field "language" would result in what are now merely language-dependent formatting instructions all of a sudden turned into textual output as well, breaking virtually every style on the biblatex side.
What happens in practice? Can you elaborate on what you mean by "breaking"?
Are you sure that the original providers of the metadata assume the "language" field should affect only the formatting of the reference entry?
If the original writer of the metadata means merely to indicate the language the article is written in and if Zotero restricts its meaning to just formatting instructions, it's Zotero which has to be fixed.
That's a challenge for something like "Language" which, typically, you only want displayed in some very select cases (you certainly wouldn't want every English publication to say "in English", say).
This is also the reason this would 'break' biblatex styles -- they'd suddenly be displaying the language of pieces when, in most cases, that's not actually desirable.
This rarely comes up in the Zotero context, so it's not, I think, a high priority to address, to be honest.
By far, most of the users of my own online database service are from nations where English isn't the primary language.The users are writing their reports in languages other than English. My users requested that I always include an "en" tag when the citation is to an English language work.
Even if BBT continues to export Zotero’s
language
fields to biblatex’slangid
fields, and never tolanguage
, which I maintain is the only sensible way, the biblatexlangid
tags can still be used to selectively generatelanguage
fields that produce the output desired by the OP, assuming the aim is to have only items tagged as Japanese, i.e., containing biblatexlangid
fields whose contents begin with “ja” (irrespective of case) receive the string “[in Japanese]” in the formatted output.In the following, biblatex's
\DeclareSourcemap
mechanism is used to generate suchlanguage
fields at runtime. Details can be found in the biblatex manual.\documentclass{article}
\begin{filecontents}[overwrite]{tmp.bib}
@article{UseLanguage,
title = {Title of UseLanguage},
author = {A. U. Thor Language},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
language = {japanese}
}
@article{UseLangid,
title = {Title of UseLangid},
author = {A. U. Thor Langid},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
langid = {Japanese}
}
@article{UseLangidAbbrev,
title = {Title of UseLangidAbbrev},
author = {A. U. Thor LangidAbbrev},
date = {1986},
journaltitle = {Journal of Engineering},
volume = {123},
number = {28},
pages = {1--12},
langid = {ja-JP}
}
@article{en,
title = {Title of Something Completetly Different in English},
author = {Doe, John},
date = {2024},
journaltitle = {Journal of Whatever},
volume = {321},
number = {1},
pages = {33--77},
langid = {en}
}
\end{filecontents}
\usepackage[sorting=none]{biblatex-chicago}
%\usepackage[sorting=none]{biblatex}
\addbibresource{tmp.bib}
\DeclareSourcemap{
\maps[datatype=bibtex]{\map{
\step[fieldsource=langid, matchi=\regexp{^ja},
final]
\step[fieldset=language, fieldvalue=Japanese]
}
}
}
\begin{document}
\nocite{*}
\printbibliography
\end{document}
(To avoid misunderstandings,
datatype=bibtex
in the above code does not mean bibtex as opposed to biblatex, but bibtex including biblatex, as opposed to e.g. biblatexml).> Even if BBT continues to export Zotero’s language fields to biblatex’s langid fields, and never to language, which I maintain is the only sensible way,
Please define "sensible". My question has been: What *practical harm* would result if BBT exports Zotero's `language` both to biblatex's `langid` and `language`? If there is no practical harm, then do it, until Zotero is "fixed". Zotero is just a tool. What matters is the result in practice.
First of all, this is the workflow if you don't use Zotero:
1. Download the bib database from the publisher's website.
2. Use it with biblatex.
3. The reference list includes the wording "[in Japanese]".
If you use Zotero and BBT, then the reference list doesn't include "[in Japanese]". Obviously, it's Zotero+BBT which needs to be fixed.
**Zotero is just a tool** to help the workflow. It's **not** a standard. That means, it's Zotero who is breaking the workflow.
What Zotero *should* do is to have two language-related fields: one to indicate the language the article is written in and the other to indicate how the title should be formatted.
Until that happens, BBT *should* export `language` both to biblatex's `language` and `langid`, not to break the workflow. This is a temporary workaround.
---
1. There are too many metadata standards and publishers' attitudes toward standards are generally lax.
2. The Zotero developers don't have the power to convince the publishers to use Zotero's strict standard.
3. Therefore, Zotero or BBT has to adapt to this word's chaotic reality.
BBT, for better or for worse, already allows what you want, it's just not the default behavior. what you are arguing is that import should make better choices. That is something we can talk about. You talk about "obviously" and "the workflow" as if your view on this is a universal standard. Given that BBT has existed for 11 years, and this is just now being debated, it doesn't look like your opinion is widely shared.
Note that the behavior you want would not round-trip either.