I've discussed this with the biblatex maintainer and we will probably aim for a style implementation of this with biblatex 3.x. With 1.7/0.9.6, the following will be possible. You will have to use the experimental biblatexml datasource format for such entries (you can still have all of your normal entries in bibtex format).
<?xml version="1.0" encoding="UTF-8"?>
<bib:entries xmlns:bib="http://biblatex-biber.sourceforge.net/biblatexml">
<bib:entry id="yanagida_zengaku_sosho_1975" entrytype="collection">
<bib:editor>
<bib:person gender="sm">柳田聖山</bib:person>
</bib:editor>
<bib:editor mode="romanised">
<bib:person>
<bib:first>
<bib:namepart initial="Y">Yanagida</bib:namepart>
</bib:first>
<bib:last>Seizan</bib:last>
</bib:person>
</bib:editor>
<bib:title>禪學叢書</bib:title>
<bib:title mode="romanised">Chūbun shuppansha</bib:title>
<bib:title mode="translated" xml:lang="en">Collected Materials for the Study of Zen</bib:title>
<bib:location>京都</bib:location>
<bib:location mode="romanised">Kyōto</bib:location>
<bib:location mode="translated" xml:lang="en">Kyoto</bib:location>
<bib:publisher>中文出版社</bib:publisher>
<bib:publisher mode="romanised">Chūbun shuppansha</bib:publisher>
<bib:date>
<bib:start>1974</bib:start>
<bib:end>1977</bib:end>
</bib:date>
</bib:entry>
</bib:entries>
There is no way to do this with bibtex format but this is no problem for biber - you can have many datasources of different formats. With the above example, you could choose to use the display format "romanised" and biber would construct the .bbl with only the romanised mode fields, for example. There will be no way to use mixed modes in the same entry however as this would need a radically enhanced .bbl format and massive internal biblatex changes which are planned for version 3.x
The above example uses the global displaymode setting (which will be in biblatex 1.7). You will also be able to set per-entry modes with an attribute on the entry, for example:
<bib:entry id="yanagida_zengaku_sosho_1975" entrytype="collection" mode="translated">
The default mode is "original" which matches fields with no mode specified too.
Edit on release of biber 0.9.6/biblatex 1.7: This is now implemented as mentioned. The default global setting is:
\DeclareDisplaymode{original,romanised,uniform,translated}
this biblatex macro is undocumented at the moment but you should be able to use it to change the global displaymode choice order. You can also set displaymode per-entry as shown above. Let me know on the biber SourceForge forum if you have problems.
General Introduction
This is do-able; but it is not easily doable. So I'm
afraid this is not an answer to the question that anyone is going to
be able to accept: just a record of the problem. The person to do this would have to understand intimately the conventions of the languages involved, and have at least some idea of how biblatex works, though that isn't any harder than escaping from the Cretan labyrinth -- just follow the thread as it snakes around.
To understand why it's possible, and why it's hard, you need to
know a bit about how biblatex works.
At the heart of every biblatex style are three files:
One (or more) file(s) with the .lbx extension contain
language definitions, such as the
appropriate strings for things like "editor", "commentator"
(obviously, different in every language), but also macros for
producing dates (consider, e.g., the difference between
English-English and American-English date conventions).
One file .cbx is responsible for generating the in-text citations,
such as "[1]" or "(Chuzzlewit 1975)".
One file .bbx is responsible for generating the bibliography list.
That is a slight oversimplification, because in some styles there is a
close linkage between .cbx and .bbx files, because in some styles
the in-text citations are (at least sometimes) more or less identical
to the full bibliographical entry. But it's sufficiently accurate to
say that the actual printing of the bibliographical data, whether it
is done in-text or in a separate bibliography or both, is largely the
work of the .bbx files.
For present purposes, let's ignore that complexity. Let's concentrate
on the .bbx files.
What a .bbx file looks like
If you look at a .bbx file, you will see a lot of things that look
like this:
\DeclareBibliographyDriver{article}{%
\usebibmacro{bibindex}%
\usebibmacro{begentry}%
\usebibmacro{author/translator+others}%
\setunit{\printdelim{nametitledelim}}\newblock
\usebibmacro{title}%
\newunit
\printlist{language}%
\newunit\newblock
\usebibmacro{byauthor}%
\newunit\newblock
\usebibmacro{bytranslator+others}%
\newunit\newblock
\printfield{version}%
\newunit\newblock
\usebibmacro{in:}%
\usebibmacro{journal+issuetitle}%
\newunit
\usebibmacro{byeditor+others}%
\newunit
\usebibmacro{note+pages}%
\newunit\newblock
\iftoggle{bbx:isbn}
{\printfield{issn}}
{}%
\newunit\newblock
\usebibmacro{doi+eprint+url}%
\newunit\newblock
\usebibmacro{addendum+pubstate}%
\setunit{\bibpagerefpunct}\newblock
\usebibmacro{pageref}%
\newunit\newblock
\iftoggle{bbx:related}
{\usebibmacro{related:init}%
\usebibmacro{related}}
{}%
\usebibmacro{finentry}}
Basically what this does is work systematically through the various
"chunks" that make up any bibliographical entry, printing them as
appropriate. But note two things. First, the order of those chunks is
fixed. And secondly, within each chunk, the driver makes heavy use of
\usebibmacro to call subsidiary bits and pieces that deal with the
logic within chunks. One of the things they often do is print
bibstrings, which are defined in .lbx files: things like "editor"
or "translator" or "volume". But where a bibmacro generates output it,
like the BibliographyDriver usually does so in an order that is hardwired.
How different languages are handled
Biblatex is able, while sticking with this same driver in every case,
to make certain concessions to differences in language: so
\bibstring for instance can work out whether to print "editor" or
"Herausgeber"; the .lbx files also define some macros which are used
to print dates and the like. And it can make (which is really the most
important) hyphenation patterns depend on the original language.
But
so much is hard baked into the .bbx despatcher system, that the sort
of reorganisation that involves fundamentally altering the order of
what is printed is tiresome to achieve. There is no
"off-the shelf" solution. One can easily say "take your bibstring
definitions for Japanese from this file, but your bibstring
definitions for English from that one; but you cannot say "take
your bibliographic template for English works from this .bbx, but
your bibliographic template for Japanese ones from that .bbx. The
.bbx files can load others, but in the end there is a single point
of entry. From this, the basic structure is hard-baked.
In order to allow the choice of language to have a more than largely
superficial effect, therefore, you have to work as follows:
- Write (or copy) a bibliography driver and/or set of
macros for each entrytype and language.
- Write a mechanism which somehow examines the language and then
despatches to the right driver.
I can think of at least two ways to do this, and there are very likely more.
One would involve playing with the data before it ever got into Biblatex, while it was in biber, effectively re-writing the entrytypes so that, say, book became
book-japanese, and then distinguishing between the book and
book-japanese types by providing them with different types. This is suggested in the comments above. There
are downsides to that for the user, though, who would have to know and
understand the implications, for instance if s/he wanted to have a
bibliography divided by type.
The other, which I used when I faced an analogous problem when dealing
with cases from different jurisdictions, is to keep a single type,
but to make the driver a wrapper whose only job is to examine the
relevant field, and then despatch on it, as well as doing bits and
pieces of cleanup, leaving it for a set of \bibmacros to do the
actual formatting. That produces some rather unlovely code, but it
does the job.
But it is key to note, that whichever of these you do, you have to
produce a new .bbx, specialised for just the languages you are
willing to handle. Even if you just copied definitions from existing
and appropriate .bbx file and renamed them as necessary (and I don't know whether, for instance,
anyone has even done one for Japanese), you'd still have a great deal
of work and testing, because you would find that your source files
made heavy use of bibmacros with the same name, but with different
definitions, and you'd have to work out which macros were safe to use,
and which need specialising, and do all that. Theoretically dull work, but
painstaking.
(Often--mostly--the bibmacros are dealing with the sort of obscure corner-cases beloved of those who dictate bibliography rules. They are capable of requiring all sorts of odd little things.)
Could one do this just from Biblatex?
I have nothing to do with maintaining biblatex, but from the outside I don't think one can realistically hold on to one's hat for this to
be tidied up in Biblatex in the near future -- even though Biblatex
has a really creditable record of being written, as far as possible, to be
expandable and adaptable. The problem is that it would not be enough
to change drivers by language (that would be fairly simple, I expect):
the .bbx files do a lot of work using bibmacros, and those often
share names. Some method for putting these macros in different
namespaces depending on where they were defined would be needed, when
the classic pattern in the existing codebase is for promiscuous
redefinition without renaming, and in various ways that approach is
cooked in.
Edited to add Also, as moewe points out in the comments, it is hard to conceive of any way of adding this feature that would not cause compatibility problems. A tiny recent change in this direction (designed to remove the parochial assumption that one's first name is also one's given name), simple as it was, hints at the possible problems. And now that Biblatex has a reasonable range of working styles, maintaining compatibility is pretty important.
Best Answer
Just so this gets an answer.
The documentation of
csquotes, which was devised by the same author asbiblatexand uses similar techniques, states on p. 2The same considerations hold for
biblatex. Sincepolyglossiadoes not offer an interface to detect the language variant used,biblatexalways uses only the main language. In your example that means that no matter whichvariantyou selected, onlyenglish.lbxis loaded, so you can not getbritish.lbxwithpolyglossia.A viable work-around for some languages is to switch to
babelinstead ofpolyglossia. Forbritishthis is certainly an option. But it might not be that easy for other languages.Starting from
biblatex3.11 you can use\DeclareLanguageMapping{english}{british}as a workaround. This is not the intended use of\DeclareLanguageMapping, but works currently as a workaround as long as you don't useenglishin your document. (There is no guarantee this will continue to work as misusing the language mapping for different dialects or languages instead of stylistic versions is explicitly discouraged in the documentation.)I have covered the difficulties with
polyglossiain my answer to \DeclareLanguageMappingSuffix, inheritance, and polyglossia in biblatex from a more technical side. I won't repeat the entire explanation, but in short the problem arises as follows.babeltreats language dialects/variants basically as languages in their own right with an.ldffile and a separate identifier.polyglossiaon the other hand has the concept of a main language that can be modified with attributes/options. One of the most prominent options is thevariant, which as it so happens corresponds for English pretty much to thebabeldialects. For Germanvariantandspellingare needed. There is neither a binding convention as to what attributes should be used for language variants, nor is there a uniform implementation of the attributes across language modules. This makes it extremely hard for packages to detect the language variant used bypolglossiaand translate it into ababellanguage name (or vice versa).