Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two-way Compatibility with BibDesk #11233

Open
foice opened this issue Apr 21, 2024 · 6 comments
Open

Two-way Compatibility with BibDesk #11233

foice opened this issue Apr 21, 2024 · 6 comments

Comments

@foice
Copy link

foice commented Apr 21, 2024

In the most recent version (5.13) it has been added import support for groups when reading a .bib file from BibDesk. That is great.
Now that the two programs both can handle groups it would be awesome to be able to go back and forth from BibDesk to Jabref.

To this end I see two issues need to be fixed still

  1. JabRef does not create a field "date-modified" nor a filed "date-added", that is standard for Bibdesk. This is a very minor thing, but breaks (very commonly used) visualizazion by date in BibDesk. I suggest to start adding such fields in JabRef too.
  2. Items added to Groups imported from BbDesk in Jabref are not saved in the equivalent BibDesk string of the .bib. Therefore if one opens the file again in BibDesk the new members of the group are missing. This seems a quite simple addition to how Jabref handles the groups which I would like to suggest so to make JabRef two-way compatible with BibDesk.
@Siedlerchr
Copy link
Member

Thanks for the feedback!

  1. JabRef has two fields for this as well:
    grafik
    This looks then like this
@Article{,
  author           = {test},
  creationdate     = {2024-04-21T18:25:51},
  modificationdate = {2024-04-21T18:25:52},
}
  1. I would suggest first creating an export "Bib desk bib format" for this as the step to verify and test the group creation
    If this works as expected, one can integrate this with an additional save option here "Save groups as bib desk groups"
grafik

@koppor
Copy link
Member

koppor commented Apr 21, 2024

We had the discussion at koppor#130. I voted for dated-added at koppor#130 (comment). At the code at

* If the old updateTimestamp setting is enabled, the timestamp field for each entry are migrated to the date-modified field.
* Otherwise it is migrated to the date-added field.
, "date-modified" is still mentioned.

I think, we opted for creationdate and modificationdate, because

Note that dates in biblatex always ends on date, like eventdate, urldate or origdate. The reason for this convention is that biblatex automatically parses these dates and provides virtual fields containing the information like eventmonth or eventyear. See \DeclareLabeldate command.

Source: koppor#130 (comment)

We did not create any ADR for our decision. We should do it. :)

What is more important? BibDesk compatibility or biblatex compatibility? Currently, I think, more BibDesk compatibility, because the date field handling for creation and modification is less often used.

This issue also refs #10370, but we cannot do much currently.

@koppor
Copy link
Member

koppor commented Apr 21, 2024

Flagged "DevCall" to refine the issue.

@foice
Copy link
Author

foice commented Apr 25, 2024

Thanks for chiming in. Yes, an export format can be a good way to test it. In the long run one wants to have that field to be created automatically so that BibDesk timestamps format is automatically satisfied.

@koppor
Copy link
Member

koppor commented May 21, 2024

Some (somewhat internal) notes of us: https://pad.riseup.net/p/JX_CKKb99QmxeNBxpHob

@koppor
Copy link
Member

koppor commented May 21, 2024

We added follow-up issues for groups:


  • For groups reading and writing, we use this issue
  • For dates, I will take care and move JabRef in the direction to read/write BibDesk date fields in future versions while respecting "old" timestamp format (and not just modify them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Free to take
Development

No branches or pull requests

3 participants