Multiscript support in biblatex/biber

[duncdrum]

I can't get the MWE from this SE thread to work.

\documentclass{article}
\usepackage{fontspec} 
\usepackage{polyglossia} 
\setdefaultlanguage{english}
\usepackage{xeCJK}
\setCJKmainfont{Hiragino Mincho Pro}

\usepackage[style=authoryear,%
            language=auto,%
            autolang=langname,%
          vform=romanised]{biblatex}
\addbibresource{literature.bib}
\usepackage{filecontents}
\begin{filecontents}{literature.bib}
@COLLECTION{yanagida_zengaku_sosho_1975,
  LANGID = {japanese},
  EDITOR = {柳田聖山},
  EDITOR_romanised = {Yanagida, Seizan},
  TITLE = {禪學叢書},
  TITLE_romanised = {Chūbun shuppansha},
  TITLE_translated_english = {Collected Materials for the Study of Zen},
  LOCATION = {京都},
  LOCATION_romanised = {Kyōto},
  LOCATION_translated_english = {Kyoto},
  PUBLISHER = {中文出版社},
  PUBLISHER_romanised = {Chūbun shuppansha},
  DATE = {1974/1977}
}
\end{filecontents}
\begin{document}
Hello World.\footcite{yanagida_zengaku_sosho_1975}
\nocite{*}

\printbibliography
\end{document}
}

The vform=romanised isn't recognised

Package xkeyval Error: `vform' undefined in families `blx@opt@pre'.

Is this still be the preferred option to include multi-lingual data in a biblatex file? It seems that romanised is a specific use case, whereas transliteration would be more fitting. Sanskrit texts for example where transcribed into Chinese, without being "romanised." Are there limits on the number of transcriptions and translation one can include?

Are there any restrictions for the contents of the LANGID field? Most catalogues that include language information seem to have these in ISO form. Does each item require one primary language, or would a bilingual edition have two LANGIDs, how do these interact with babel/polyglossia?

[plk]

The multiscript code was never in a released version and was in a separate git branch but it is currently in limbo and hasn't been updated in a long time because it really over-complicated the biblatex internals and I hit several problems. I would like to look at it again at some point but at the moment it's not really useable.

[duncdrum]

I see so for biblatex export of our records, we should wrap transliteration and translation into standard biblatex fields?

...
EDITOR = {Yanagida~Seizan, 柳田聖山},
...

since biblatexml seems to be in a similar state of limbo?

[plk]

It's not so much anything to do with the data source format (biblatexml has had a lot of work for version 3.4 which will be released soon) but the internals which handle multi-script. There is no current obvious way to deal with this apart from perhaps with the related entry functionality - you could have multiple entries with RELATED fields and then you'd have to write driver macros to support this. You could ask on TSE. That format you suggest won't work because name fields have to be parsed by the usual bibtex name parsing rules.

[maieul]

dear @plk, I will be glad to make any feedback for test in such features. If I remember well conversation on previous topic, two points are very important:

• the fact that biblatex and biber setting must be correlated
• the possibility to specify normalisated form in different language for different field of the same entry.

[u-fischer]

I'm too still interested in this topic. Imho problems are

• lists (of location or names) as it can happen that only some names needs a translation/transscription.
• the handling of names where "first name lastname" doesn't work in the same way as in english.
• How to avoid too complicated "if this variant exists then ... else if this variant exist ... else ..." chains in the drivers.

[plk]

It's exactly point three you mention that made me think that the last PoC I did of this was not the right way - it got extremely complicated and ugly in the internals. Point two about names should I think be possible already with the name changes in 3.3 - that was partly the motivation - you can define custom name parts and also customise how sort keys are constructed for name parts (see 93-nameparts.tex sample file which implements basic Russian patronymics).

A problem I forsee is how to determine labelname, labeltitle etc. without demanding that every field they reference has every script variant defined. The alternative is a messy interface to select the script variant of them and I'd rather avoid that.

[u-fischer]

Can the name parts interface handle different name types in one author list in one go? That means a chinese name, a russian name with patronoymics and a german? And the main question: How can one manage a bib in xml-format. Things like your answer here http://tex.stackexchange.com/a/308761/2388 looks very good but I doubt that user want to write xml manually.

Perhaps biber could handle an input syntax like this:

 author={\namepart{family}{Fischer} \namepart{given}{Ulrike}  and \namepart{family}{...} \namepart{prefix}{von}  }

Then one wouldn't have to convert everything to xml to explore the power of the \namepart system.

Regarding the labelname: I think one shouldn't overdo the automation but allow user to define them manually if the wishes gets to special, e.g. labelname_typeX={...} with some interface to select such labelnames.

[plk]

I would need to experiment a bit but essentially, any name parts defined by \DeclareDatamodelConstant[type=list]{nameparts}{ ... } are available to names. This doesn't really address the multi-script requirement though. The XML format has had a lot of work for 3.4. You don't need to write it by hand - tool mode can convert to/from this (I use the XML format for my own work).

I am a bit loathe to extend the bibtex format as it usually means hacking the btparse C library and this is painful and fragile. It's also a general CPAN module and so it must always remain backwards compatible with any generic bibtex usage.

[u-fischer]

The problem with converting bib<->xml is that it will (probably) only work as long the content is usable in both formats. But I do understand that extending the format of normal name fields is difficult. What about a new field format with a strict input syntax with name parts? Then one could use xauthor={....}.

Btw: I get errors when converting to xml and back to bib:

    G:\biblatextest>biber --tool --output-format=biblatexml biblatex-examples.bib
    G:\biblatextest>biber --tool --output-format=bibtex biblatex-examples_bibertool.bltxml

[plk]

You need to use --input-format=biblatexml on the second run. I suppose I could auto-detect this from the filename extension.

[plk]

@u-fischer - I have added an extended name format for bibtex data sources when using biber. It allows you to specify the name parts explicitly and you can mix and match this with normal bibtex names:

AUTHOR = {Alan Smith and family=Brown, prefix=de, given=Robert}

I'd rather not encourage tex markup in names, hence this format (which has to be handled in biber anyway).

Detection of which parsing routine to use is automatic but you can turn off extended name format parsing with a biber flag in case of issues. It also allows explicit specification of prefices and supports any custom nameparts defined in the data model. See the biber PDF doc and the 93-nameparts.tex which comes with biblatex which uses both biblatexml and this extended bibtex format. This is in 2.6/3.5 dev versions.

[u-fischer]

This sounds very good, I will try it tomorrow -- and it is naturally ok that it not a TeX-syntax, I only used it because I'm used to.

[plk]

Actually, you are right about the bib<->biblatexml round-trip. There is currently no support for biblatexml->bib, only bib->bib.

EDIT: See below, this is now possible - tool mode can now convert between anything, including the extended name format and normal name format.

[Shinoto-github]

I am new to this discussion and cannot really help developing code etc.

But I can speak Japanese and have rudimentary knowledge of Chinese and Korean, and I do write in the humanities in several languages, using multilingual bibliographies (including Western languages). I will be glad to help with comments if you wish so and can test documents. If this is more of a nuisance, do not hesitate to tell me. This is OK for me.

As for author names, the solution of plk AUTHOR = {Alan Smith and family={Brown}, prefix={de}, given={Robert}} looks good. There is another case with generation names in Korean and Chinese; some want them mentioned isolated, others include them into their personal (given) name.

This is all for now.

[plk]

This could be helpful when I get time to look more into it. The new name format you mention is already in bibaltex 3.5/biber 2.6 development versions (on sourceforge) and you can define any new nameparts you need to deal with things like generation names. However, the main issue with multilingual support is having multiple copies of the same field in the same bibliography data entry and this is something which is quite hard to implement.

[Shinoto-github]

Great to hear about the name format in the development versions!

I see three main problems with Far Eastern sources which I will explain below. If I understand something wrong, please do not take your precious time to correct my view. I would be embarrassed if my comments steal your time rather than help finding a solution.

1. Different formats in the same bibliography. Some Far Eastern journals request separation of Western and Far East languages; so it is easy to get two different bibliographies and it should be easy to apply a style that is appropriate to the language. But since the style is chosen in the preamble, it must be a universal style for different cases.
2. Brackets for certain fields (like series titles) are different to those in Western languages. If a package like csquotes can deal with Japanese etc. brackets, and we could choose them in a modification of the style, that would make the bibliography look a lot better.
3. As for multiple name versions, there are mostly these types: (1) Translations into different languages (for institutions), (2) Transscripts according to different transscript systems into different writing systems, (3) Original writing, and (4) Transcription for identification. The fourth is particularly important in styles similar to authoryear, where the author is identified and mentioned once, whereas each entry might have a different original or transscript or translation. -- But basically, every field can have these variations, a title can be translated or transscribed as well.

For the time being, I am writing my biblatex files with the ID transscript (4) in romanised form into the normal author and editor field, for the other cases I use a field-naming-system that adds the type and the intended language or writing system to the field name. E.g. "author" comes as "author-trsscpt-hepburn" or "author-trslation-de" or "author-orig-ja" etc. -- Whenever I use the entries, for now I use regular expressions to create the fields that the authoryear style recognises in order to get the respective data printed.

[moewew]

The new way to give name parts explicitly is really useful. I still think that the biblatexml is a bit too overwhelming for the user, while .bib files are very easy to understand.

Would it also be possible to give the sortnamekeyscheme in this model (per-name)?

[plk]

@moewew - yes, that's important. It should work now for per-namelist and per-name scope in bibtex datasources - see the biblatex doc on \DeclareSortingNamekeyScheme.

I agree about biblatexml - until there is some GUI interface to a backend XML format like this, it's not very easy to see things at a glance even though it's conceptually easier and less prone to errors.

[moewew]

That works very well, thank you.

I noticed that Biber complains (use of uninitialized value in (.)) if a name does not include a family part. The output is fine, but it seems Biber expects names to have a family part (maybe this is connected to the next observation). With the new name scheme it would probably be necessary to allow for customisation of the uniquename option (per sortnamekeyscheme or something new).

This all came up in Bibtex/Biber: how to cite an author using Ethiopian conventions? on TeX.SX.

MWE (for the use of uninitialized value in (.))

\documentclass{article}
\usepackage{filecontents}

\begin{filecontents*}{\jobname.bib}
@book{james,
  author  = {given=James},
  title   = {Test},
  date    = {1983}
}
\end{filecontents*}

\usepackage[style=authoryear]{biblatex}

\addbibresource{\jobname.bib}

\begin{document}
\textcite{james}
\printbibliography
\end{document}

For me the allure of the .bib format is that you don't need a GUI to work with it comfortably. (Judging by the number of questions on TeX.SX about JabRef and other exporters they can even cause more problems than they solve.) Even though I have a soft spot for XML and agree that it is a nicer format to store the data, the biblatexml format is a bit too verbose for me to work with manually.

[plk]

Yes, I need to remove the last traces of assumption that every name has a family name - that's been hard-coded into biblatex/biber for a long time. Then I think uniquename etc. need to be customisable. Looking into it.

[simifilm]

Probably a subject for a separate discussion: While I really like the new flexible data model for names, I think biblatex finally reaches a point where we have to think more about how GUIs can handle the changes.

I just added pen names to biblatex-fiwiwhich works fine. But if I have an entry like

Author = {given={William}, family={Atheling}, suffix={Jr.}, truefamily={Blish}, truegiven={James}},

in a .bib file, BibDesk, my GUI of choice, can't handle it anymore. And, of course, the biblatexml can't be handled by any application.

I realize that the biblatex devs can't also take care of the various GUIs, and unfortunately, the BibDesk haven't been very forthcoming about biblatex in the past, but I think some kind of exchange or communication between with some GUI devs could be established, this would be a big boon.

OTOH, if I end up with a .bib file which I can only edit with a text editor, that would, at least for me, be a big step backwards.

[maieul]

indeed, the Bibdesk team is not very open to biblatex. For example, they don't want mechanism of nested crossref.

However, may I suggest to use : as separator inside field

Author = {given:{William}, family:{Atheling}, suffix:{Jr.}, truefamily:{Blish}, truegiven:{James}}

That will make the GUI be compatible without any modification

[plk]

Good idea - I only use Emacs and so I am not really aware of the GUI situation.

[maieul]

I have tested with bibdesk: ":" is working. What should be tested is, I think, Zotero (with https://github.com/retorquere/zotero-better-bibtex) and JabRef.

[u-fischer]

However, may I suggest to use : as separator inside field

I can't test it, but why should bibdesk care about the separator (colon or equal sign)? Imho the only thing that should matter in a "normal" bibtex application is the numbers of commas.

[plk]

I imagine it confuses it with the = after the field name. I will make the separator configurable.

[maieul]

I imagine it confuses it with the = after the field name.

It is ;-)

[u-fischer]

I imagine it confuses it with the = after the field name.

It is ;-)

This would be a bug in bibdesk. Fields and names should be allowed to contain an equal sign. Does an equal sign in other fields break too?

[maieul]

I told something wrong. The example from @simifilm is working for me (except that bibdesk is not able to get the correct information�)

So for now, maybe wait test in more common GUI.

[simifilm]

@maieul: I realized that it depends on whether "Use normalized author names when saving" is activated. With this function turned off, the data remains intact.

Still, my post wasn't really about this specific problem but more about the general issue. I do understand why biblatex is moving away from BibTeX (the format), but there definitely is a downside to this. biblatex/biber is turning more and more in an isolated solution which does not work properly with the existing ecosystem.

I do not mean this as criticism of the devs work, but I think it is an issue which should not be ignored.

[plk]

biblatex won't stop supporting the usual bibtex format but that format isn't adequate for things people want/need to do these days. I wouldn't say that it doesn't work with the existing ecosystem - if you don't use the extended features, it does.

[plk]

All, please try the latest 3.5/2.6 from SF - the separator is now customisable with the biber option xnamesep, default is still '=' unless there is a consensus it shouldn't be. The uniquename changes will take time as it's complicated because internally, biber generally assumes that "family" is the most reliable name part which it probably shouldn't. @moewew - The "missing family name" error is fixed for now.

[moewew]

Indeed the error messages are gone now. Thank you very much.

[simifilm]

@plk I completely understand the reasons why biblatex needs to leave traditional BibTeX behind to make its advanced features work. And I do know the limitations of BibTeX very well. It's just that as a user you are currently in a strange place if you want to make use of these features. You end up with data which sort of looks like BibTeX but which gets harder and harder process with the existing tools. And while biblatexml might in theory be the solution, there are no tools at all to work with it. And editing XML by hand just isn't a lot of fun.

[plk]

3.5/2.6 have now removed hard-coded use of nameparts in uniqueness information generation. This is now controlled by the new \DeclareUniquenameTemplate macro which defaults to what was previously hard-coded. I haven't tested this much yet but you should be able to change this to construct uniqueness information for uniquename/uniquelist from arbitrary nameparts.

[plk]

An update - 3.5/2.6 have now, hopefully, all hard-coded use of legacy bibtex nameparts removed and replaced by datamodel driven nameparts. This means more flexibility in extracting nameparts for labelling (see the new \DeclareLabelalphaNameTemplate macro) and a generalisation of the sortgiveninits and giveninits options. With this release, the internals should no longer depend on legacy bibtex name formats. Also, the extended bibtex name format now supports useprefix as a per-namelist and per-name option.

[plk]

Another update. "Tool mode" for biber is completely re-written in version 2.6 - it was rather limited before and generated output only from bibtex input and only in a narrowly defined way. Now it generates output from the internal object model and so can do biblatexml<->bibtex and can also now convert between the standard and extended name formats (see the --output-xname option for tool mode). Naturally information only possible in the extended format (per-namelist and per-name options, for example), are lost on conversion to the standard name format.

[plk]

@u-fischer, @moewew et al, I would like to get some sort of "requirements" document for the multiscript features together, essentially, what you would expect at the user level as features. I can think of the following:

• Ability to print multiple variants of a field (not just names) when processing a single entry.
• Ability to switch for some scope (document, refcontext etc.) to one particular variant for all entries within the scope.
• Language switching when printing a field variant is automatic

[maieul]

• possibility to have differents fields with different language associated (for example a booktitle in English and a title in French)
• field variant should not be related to a specific language (for example: title_original could be for some entries in latin and for other one in greek)

[norbusan]

Hi Phil, thanks a lot for your inquiry. I am currently working on a project that collects Chinese philosophy resources. What I see here - and what I want to do is:

• represent not only publications, but other types in .bib files (people, terms, ...)
• cross-reference other entries easily

Concerning the entry format, I just can tell you what we are having here. For example, for a "person" type I have several different writing styles (hanzi, pinyin, pinyin_notone) plus alternative names etc.

I think what would be useful if one could give the same "object" (title, name, ...):

• as you said, ability to priint multiple variants of the above (hanzi, or pinyin, or notone, or for my own usage in Japanese, kanji, furigana, romaji)
• concerning your second suggestion: I am not sure how to read that, but it would be nice to have some "writing style aware" citation commands. So that one can set some flag (in one way or the other) and then \cite would create references in a specific form. Maybe one could define special format directives (user supplied) for citation styles (maybe this is already possible?)
• integration with the xetex font switching automatism (we use \xeCJKDeclareSubCJKBlock)?
• cross references: If one defines person as bib entry type, one should be able to use author = {\somecmd{nnn} and First Last}, and the first part would refer to an entry in a bib file, while the other is treated normally.

Well, this is what I can think of for now. I will ask my colleagues in China to comment, too!

Thanks

[plk]

@norbusan - do the babel/polyglossia font switching mechanisms work for you? They are already integrated, I am just wondering if there are additional things we need to think about.

[plk]

@norbusan - also, it seemed that the necessity of having objects like people etc. was a way of semi-implementing multiscript for names or does the name cross-referencing have a use-case that might warrant a new feature apart from the need for multiscript?

[norbusan]

@plk I didn't write the xetex code, but my collaborators use xeCJK which does font switching based on code points (as far as I recollect).

Having objects like people is somehow necessary as we are having a glossary of people and want to refer to it both as authors of books as well as in the running text. This is something separate from multi-script I guess, though.

[pcdi]

@plk Regarding your question about a “requirements” document: maybe the following two questions (perhaps not so much their respective solutions) on TeX.sx are of interest to you. The problems and requirements that the OP has seem typical to me, as I am in a related field.

• Chicago-style citations of CJK documents (e.g. American Oriental Society): Name order; transcribed/translated titles
• Chicago-style citations of CJK documents #2

[duncdrum]

@plk any news on best practices for multi-lingual bibliographies in biblatex?

[plk]

@moewew - I suggest we start gathering requirements and interface design here again. I have been thinking about this a bit and would like to pick this up again.

[yannis1962]

I think that there are two levels: (1) we process all non-Latin material the same way, (2) we separate by language+script combination. In the first case, there should be, for every entry, an "original" entry, a “transcribed” entry and a “translated” entry (the translation being in the main language of the document). That would give:

@inproceedings{makri, author={Μακρῆ-Τσιλιπάκου, Μαριάνθη and Παπαδοπούλου, Εὐανθία}, author:TRANSCRIPTION={Makrê-Tsilipakou, Marianthê and Papadopoulou, Evanthia}, editor={Παυλίδου, Θεοδοσία-Σούλα}, editor:TRANSCRIPTION={Pavlidou, Theodosia-Soula}, title={Συμφωνία/Διαφωνία: Ἀλληλεγγύη καὶ Ἀντιπαλότητα στὶς Συνομιλίες Γυναικῶν καὶ Ἀντρῶν}, title:TRANSLATION={Agreement/Disagreement: Solidarity and Adversity in Discussion between Women and Men}, title:TRANSCRIPTION={Symphonia/Diaphonia: Allêlegguê kai Antipalotêta stis Sunomilies Gunaikôn kai Andrôn}, booktitle={Γλώσσα - Γένος - Φῦλο}, booktitle:TRANSLATION={Language - Gender - Sex}, booktitle:TRANSCRIPTION={Glôssa - Genos - Phulo}, publisher={Ἰνστιτοῦτο Νεοελληνικῶν Σπουδῶν}, publisher:TRANSLATION={Institute of Modern Greek Studies}, publisher:TRANSCRIPTION={Institouto Neoellênikôn Spoudôn}, address={Θεσσαλονίκη}, address:TRANSLATION={Thessalonica}, address:TRANSCRIPTION={Thessaloniki}, pages={81--117}, edition={2η ἔκδοση}, edition:TRANSLATION={2nd edition}, year={2006} }

where I add the :TRANSCRIPTION and :TRANSLATION tag whenever necessary (it makes no sense to transcribe the words for 2nd edition, as it makes no sense to translate personal names, but it makes sense to translate a town's name)

The second case is when we really want to be precise about the language and the writing system, because we may use the same BIB file for documents in many languages and writing systems:

@inproceedings{makri, language={GR:GR}, author:GR:GR={Μακρῆ-Τσιλιπάκου, Μαριάνθη and Παπαδοπούλου, Εὐανθία}, author:GR:LA={Makrê-Tsilipakou, Marianthê and Papadopoulou, Evanthia}, editor:GR:GR={Παυλίδου, Θεοδοσία-Σούλα}, editor:GR:LA={Pavlidou, Theodosia-Soula}, title:GR:GR={Συμφωνία/Διαφωνία: Ἀλληλεγγύη καὶ Ἀντιπαλότητα στὶς Συνομιλίες Γυναικῶν καὶ Ἀντρῶν}, title:EN:LA={Agreement/Disagreement: Solidarity and Adversity in Discussion between Women and Men}, title:GR:LA={Symphonia/Diaphonia: Allêlegguê kai Antipalotêta stis Sunomilies Gunaikôn kai Andrôn}, booktitle:GR:GR={Γλώσσα - Γένος - Φῦλο}, booktitle:EN:LA={Language - Gender - Sex}, booktitle:GR:LA={Glôssa - Genos - Phulo}, publisher:GR:GR={Ἰνστιτοῦτο Νεοελληνικῶν Σπουδῶν}, publisher:EN:LA={Institute of Modern Greek Studies}, publisher:GR:LA={Institouto Neoellênikôn Spoudôn}, address:GR:GR={Θεσσαλονίκη}, address:EN:LA={Thessalonica}, address:GR:LA={Thessaloniki}, pages={81--117}, edition:GR:GR={2η ἔκδοση}, edition:EN:LA={2nd edition}, year={2006} }

Here GR:GR means Greek language, Greek alphabet, GR:LA means Greek language, Latin alphabet, EN:LA means English language, Latin alphabet. People could then add other combinations, ad libitum :

booktitle:FR:LA={Langue - genre - sexe}, booktitle:DE:LA={Sprache - Genus - Geschlecht},

If you implement the second approach then one has to put somewhere in the preferences the fact that MAIN_LANGUAGE=EN MAIN_WRITING_SYSTEM=LA so that the system will use no translation and no transcription for EN:LA entries, translation only for all :LA entries and translation and transcription for all :XX entries, where XX ≠ LA.

[pauloney]

Not only that, we should also add "TRANSLITERATION" that in most cases is more important than transcription or translation:

https://scriptsource.org/cms/scripts/page.php?item_id=entry_detail&uid=gslmka8xq3

and

http://www.lipikaar.com/support/difference-between-transcription-transliteration-translation

but above all, we should introduce BCP47 for language tags instead of the limited and confusing double-character tag (GR, FR, EN, ...) that is not good enough for the job.

Paulo Ney

On Thu, Sep 12, 2019 at 3:04 AM yannis1962 notifications@github.com wrote:

I think that there are two levels: (1) we process all non-Latin material the same way, (2) we separate by language+script combination. In the first case, there should be, for every entry, an "original" entry, a “transcribed” entry and a “translated” entry (the translation being in the main language of the document). That would give:

@inproceedings{makri, author={Μακρῆ-Τσιλιπάκου, Μαριάνθη and Παπαδοπούλου, Εὐανθία}, author:TRANSCRIPTION={Makrê-Tsilipakou, Marianthê and Papadopoulou, Evanthia}, editor={Παυλίδου, Θεοδοσία-Σούλα}, editor:TRANSCRIPTION={Pavlidou, Theodosia-Soula}, title={Συμφωνία/Διαφωνία: Ἀλληλεγγύη καὶ Ἀντιπαλότητα στὶς Συνομιλίες Γυναικῶν καὶ Ἀντρῶν}, title:TRANSLATION={Agreement/Disagreement: Solidarity and Adversity in Discussion between Women and Men}, title:TRANSCRIPTION={Symphonia/Diaphonia: Allêlegguê kai Antipalotêta stis Sunomilies Gunaikôn kai Andrôn}, booktitle={Γλώσσα - Γένος - Φῦλο}, booktitle:TRANSLATION={Language - Gender - Sex}, booktitle:TRANSCRIPTION={Glôssa - Genos - Phulo}, publisher={Ἰνστιτοῦτο Νεοελληνικῶν Σπουδῶν}, publisher:TRANSLATION={Institute of Modern Greek Studies}, publisher:TRANSCRIPTION={Institouto Neoellênikôn Spoudôn}, address={Θεσσαλονίκη}, address:TRANSLATION={Thessalonica}, address:TRANSCRIPTION={Thessaloniki}, pages={81--117}, edition={2η ἔκδοση}, edition:TRANSLATION={2nd edition}, year={2006} }

where I add the :TRANSCRIPTION and :TRANSLATION tag whenever necessary (it makes no sense to transcribe the words for 2nd edition, as it makes no sense to translate personal names, but it makes sense to translate a town's name)

The second case is when we really want to be precise about the language and the writing system, because we may use the same BIB file for documents in many languages and writing systems:

@inproceedings{makri, language={GR:GR}, author:GR:GR={Μακρῆ-Τσιλιπάκου, Μαριάνθη and Παπαδοπούλου, Εὐανθία}, author:GR:LA={Makrê-Tsilipakou, Marianthê and Papadopoulou, Evanthia}, editor:GR:GR={Παυλίδου, Θεοδοσία-Σούλα}, editor:GR:LA={Pavlidou, Theodosia-Soula}, title:GR:GR={Συμφωνία/Διαφωνία: Ἀλληλεγγύη καὶ Ἀντιπαλότητα στὶς Συνομιλίες Γυναικῶν καὶ Ἀντρῶν}, title:EN:LA={Agreement/Disagreement: Solidarity and Adversity in Discussion between Women and Men}, title:GR:LA={Symphonia/Diaphonia: Allêlegguê kai Antipalotêta stis Sunomilies Gunaikôn kai Andrôn}, booktitle:GR:GR={Γλώσσα - Γένος - Φῦλο}, booktitle:EN:LA={Language - Gender - Sex}, booktitle:GR:LA={Glôssa - Genos - Phulo}, publisher:GR:GR={Ἰνστιτοῦτο Νεοελληνικῶν Σπουδῶν}, publisher:EN:LA={Institute of Modern Greek Studies}, publisher:GR:LA={Institouto Neoellênikôn Spoudôn}, address:GR:GR={Θεσσαλονίκη}, address:EN:LA={Thessalonica}, address:GR:LA={Thessaloniki}, pages={81--117}, edition:GR:GR={2η ἔκδοση}, edition:EN:LA={2nd edition}, year={2006} }

Here GR:GR means Greek language, Greek alphabet, GR:LA means Greek language, Latin alphabet, EN:LA means English language, Latin alphabet. People could then add other combinations, ad libitum :

booktitle:FR:LA={Langue - genre - sexe}, booktitle:DE:LA={Sprache - Genus - Geschlecht},

If you implement the second approach then one has to put somewhere in the preferences the fact that MAIN_LANGUAGE=EN MAIN_WRITING_SYSTEM=LA so that the system will use no translation and no transcription for EN:LA entries, translation only for all :LA entries and translation and transcription for all :XX entries, where XX ≠ LA.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/plk/biblatex/issues/416?email_source=notifications&email_token=AAR7WYRTUZIWE3VEBLRRVTDQJIH3HA5CNFSM4CB64K52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RLNWY#issuecomment-530757339, or mute the thread https://github.com/notifications/unsubscribe-auth/AAR7WYRKXUVH4L6NDSCAS7DQJIH3HANCNFSM4CB64K5Q .

[yannis1962]

Transliteration is important when you don't have the original script, so that you are able to reconstruct it. But when you already have the original script (and that's the whole idea), what you want to add is how it is pronounced. So IMHO in cases where the original script is included, transliteration is not more important than transcription, on the contrary.

But both ca be useful, no doubt on that.

As for BCP47 why not, it would be en:Latn el:Latn el:Grek (and it's up to the user to choose whether el:Grek is transcription or transliteration or something in between as in my case)