You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your suggestion for improvement related to a problem? Please describe.
I am working a lot with Chinese sources. Since the name formatting is different from Western names, I am using the extended name format, which adds custom nameparts.
An overview of how this works with Ethiopian names is provided in this TeX.StackExchange answer. In summary, in addition to the nameparts family, given, etc., I am adding a namepart called cjk, which holds the Chinese characters for the person.
These changes are made through biblatex's datamodels: An example .dbx datamodel file can be found here, the corresponding .tex document here, and the resulting PDF here.
In my .bib entries, I am then able to use, for example:
While this approach works flawlessly with biblatex/biber, it has certain drawbacks when working with JabRef:
JabRef sees the explicit nameparts as part of the name, so the above example shows cjk=张康之 in the Author/Editor column of the main table. Depending on what namepart comes first, JabRef will show that namepart. For example, if the order were as follows:
JabRef would show family=Zhang in the Author/Editor column.
The same behavior appears in the entry preview, where the author shows up as cjk or family, respectively.
This naturally also extends to JabRef's search function, where family=Zhang and Zhang would appear as two distinct "last names".
This behavior also emerges when no custom nameparts are used, so it also applies to
author = {family=lastname, given=firstname},
Describe the solution you'd like
Explicit nameparts should be ignored for display purposes and treated as equal to implicit nameparts for internal purposes. Additionally, checking for "Names are not in standard biblatex format" should take into account any custom additions that can be provided to JabRef via the standardized biblatex .dbx datamodel file.
Is your suggestion for improvement related to a problem? Please describe.
I am working a lot with Chinese sources. Since the name formatting is different from Western names, I am using the extended name format, which adds custom
namepart
s.An overview of how this works with Ethiopian names is provided in this TeX.StackExchange answer. In summary, in addition to the
namepart
sfamily
,given
, etc., I am adding anamepart
calledcjk
, which holds the Chinese characters for the person.These changes are made through biblatex's datamodels: An example
.dbx
datamodel file can be found here, the corresponding.tex
document here, and the resulting PDF here.In my
.bib
entries, I am then able to use, for example:author = {cjk=张康之, family=Zhang, given=Kang\-zhi, nametemplates=cjk},
While this approach works flawlessly with biblatex/biber, it has certain drawbacks when working with JabRef:
JabRef sees the explicit
namepart
s as part of the name, so the above example showscjk=张康之
in the Author/Editor column of the main table. Depending on whatnamepart
comes first, JabRef will show thatnamepart
. For example, if the order were as follows:author = {family=Zhang, given=Kang\-zhi, cjk=张康之, nametemplates=cjk},
JabRef would show
family=Zhang
in the Author/Editor column.The same behavior appears in the entry preview, where the author shows up as
cjk
orfamily
, respectively.This naturally also extends to JabRef's search function, where
family=Zhang
andZhang
would appear as two distinct "last names".This behavior also emerges when no custom
namepart
s are used, so it also applies toDescribe the solution you'd like
Explicit
namepart
s should be ignored for display purposes and treated as equal to implicitnamepart
s for internal purposes. Additionally, checking for "Names are not in standard biblatex format" should take into account any custom additions that can be provided to JabRef via the standardized biblatex.dbx
datamodel file.Additional context
Related info: plk/biblatex#416
https://tex.stackexchange.com/a/320738
https://tex.stackexchange.com/a/390393
The text was updated successfully, but these errors were encountered: