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

Inconsistent casing of custom field names #10590

Open
2 tasks done
myshevchuk opened this issue Oct 27, 2023 · 2 comments
Open
2 tasks done

Inconsistent casing of custom field names #10590

myshevchuk opened this issue Oct 27, 2023 · 2 comments

Comments

@myshevchuk
Copy link

myshevchuk commented Oct 27, 2023

JabRef version

5.11 (latest release)

Operating system

macOS

Details on version and operating system

MacOS 13.6 (22G120)

Checked with the latest development build (copy version output from About dialog)

  • I made a backup of my libraries before testing the latest development version.
  • I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

Casing of custom field names is inconsistent in several different ways as described below. I believe these inconsistencies may have been introduced with #9993, at least partly.

In the Details pane, casing does not respect the bibtex file in contrary to what is declared in this comment

  1. Create a new custom field in the biblatex source tab
  2. Make the field name upper case, e.g. Newfield
  3. Save, close and reopen file
  4. Observe that in the Other fields tab the newfield field name is lowercased, as it is in the BibTeX file. In fact, lowercase has been enforced and saved into file!
  5. Observe that built-in BibTeX fields such as Author or Title are always uppercase in the UI and always lowercase in the BibTeX file.

Now, there is a way to make custom fields appear uppercase, but

In the Details pane, built-in tabs such as Required fields or Optional fields only partially respect JabRef preferences

  1. Go to Preferences > Entry types and choose the type of your test BibTeX entry, e.g. "Book"
  2. Create a custom field Newfield (uppercase) within that entry type, also make one of the existing built-in fields such as Author lowercase
  3. Export preferences into an xml file
  4. Quit and start JabRef anew
  5. In the Details pane, observe that both Newfield and Author are uppercase, although one would expect author to become lowercase
  6. In the xml file, observe that author is lowercase while Newfield is uppercase
  7. In the xml file, observe that built-in field names are all lowercase, while Newfield is uppercase. Newfield becomes lowercase when done so through preferences.
  8. JabRef enforces the built-in field names to appear always uppercase in the UI and always lowercase in files, both xml prefs and BibTeX bib sources.

In the Details pane, custom tabs do not respect anything, neither BibTeX source, nor preferences.

  1. Go to Preferences > Entry Editor and create a custom tab such as Fields:author;newfield
  2. Observe that no matter what, author always appears uppercase and newfield always appears lowercase.

Summary

Currently, it is not possible to have a consistent casing across the Details pane and a BibTeX file:

  1. Built-in field names are always lowercase
  2. Custom field names can be made both, but not in custom tabs
  3. Lowercase is enforced in bib files
  4. Lowercase is almost exclusively enforced in xml preferences file - only custom fields can be saved uppercase in jabref-entrytype fields, though not in customTabFields fields.

Appendix

The below screenshots should illustrate what is written above.

Preferences > Entry types

Screenshot 2023-10-27 at 15 15 59

Required fields tab

Screenshot 2023-10-27 at 14 53 20

Custom Fields tab

Screenshot 2023-10-27 at 14 59 10

biblatex source tab

Screenshot 2023-10-27 at 14 59 54

test.bib opened in another editor

Screenshot 2023-10-27 at 15 00 40

@koppor
Copy link
Member

koppor commented Oct 28, 2023

Thank you for the report.

Maybe it is too late here, but what is the Details pane? Is it our entry editor?

Current comments/state. Need to discuss this in our devcall.

  1. When adding a field in the biblatex source tab, there is no sync to the customized entry setting. Thus, the behavior could be "random".
  2. We decided to have JabRef defining the build-in BibTeX fields (including casing) - and that a user cannot change that.
  3. required/optional fields grouping in the entry editor is a field we did not touch for a long time. We could resume working here.

I think, I understood, what does not work, but I did not quite understand of the solution what you disre. I try to guess:

  1. Adding new fields in BibTeX source should lead to an addition to the customization
  2. Changing a field case in BibTeX source should lead to a change in the customization (to refactor all other fields)
  3. Changing casing for Standard fields should also be reflected (enabling overwrite of JabRef's custom style. Refs Add blog post on changes of our .bib serialization blog.jabref.org#47)
  4. Fix configuration of custom tabs to show the field casing as configured in the entry type customization
  5. Have preferences export/import respecting the configuration of custom entry types

@myshevchuk
Copy link
Author

myshevchuk commented Nov 2, 2023

Hi, thanks a lot for your reply.

Maybe it is too late here, but what is the Details pane? Is it our entry editor?

Oops, yes I meant Entry Editor 🤦

  1. When adding a field in the biblatex source tab, there is no sync to the customized entry setting. Thus, the behavior could be "random".

What I meant is no matter how you edit the file - even in an external editor - at the end of the day JabRef takes liberty to forcefully save it with field names lowercased. I'm personally fine with this style, I actually prefer it. Still I believe this behavior should be customizable. BibTeX is an open format, BibTeX engines are agnostic to casing and so should be a bibliography manger... With respect to the current issue, the BibTeX source could be JabRef's source of truth for UI casing, it should not necessarily be such, though. I somehow can imagine it would be quite painful to try to sync BibTeX source to the customized entry setting. Better the other way around - this is one possible solution to the current issue - sync the customized entry setting to the BibTeX file. That is the customized entry setting becoming the only and sole source of truth for entry formatting, such as casing of BibTeX @EntryTypes vs @entrytypes and FieldNames vs fieldnames or even fieldNAMES - the user is absolutely free to decide.

  1. We decided to have JabRef defining the build-in BibTeX fields (including casing) - and that a user cannot change that.

It is clear that JabRef needs a sane default of built-in fields, but the casing "case" is not so obvious. Why is it so important?

  1. required/optional fields grouping in the entry editor is a field we did not touch for a long time. We could resume working here.

The problem is with custom field groupings. There are required field and optional fields tabs, which are built-ins. And then there is an absolutely fantastic feature to create one's own custom tabs. Whereas the built-in tabs such as required/optional fields do respect customized entry settings, the custom tabs disregard customized entry settings and always display built-in fields uppercase and custom fields lowercase. So if one creates a custom Entry Editor tab with built-in and custom fields in it, such as Author and Newfield, then the built-in Author will always be displayed uppercase and newfield will always be displayed lowercase, even though Newfield is uppercase in the customized entry setting. This is shown in the third screenshot and currently cannot be changed by the user.

On one hand, this is the issue I'm reporting. On the other hand, it is just a symptom. It seems to me that the cause is the lack of a single source of truth for UI formatting. Somehow, the built-in tabs and custom tabs are handled separately, and so are the built-in and custom fields. I don't know the internals of JabRef nor do I have much experience with Java, but it seems logical to handle these things uniformly - with a single method or with the same function and in one place, either immediately after reading the data or immediately before presenting it to the user - you know that better than I do.

  1. Adding new fields in BibTeX source should lead to an addition to the customization

That would probably be quite a bit of a task. How will you decide which entry's fields to use in customization?

  1. Changing a field case in BibTeX source should lead to a change in the customization (to refactor all other fields)

It is a potential solution, although not a very intuitive one. Intuitively, I'd look for an option in preferences to change how a program formats its data and not the other way around.

  1. Changing casing for Standard fields should also be reflected (enabling overwrite of JabRef's custom style. Refs Add blog post on changes of our .bib serialization blog.jabref.org#47)

Yes!

  1. Fix configuration of custom tabs to show the field casing as configured in the entry type customization

Yes, please!

  1. Have preferences export/import respecting the configuration of custom entry types

That would be awesome!

If I may, I would suggest two possible solutions, either:

a) make customized entry setting the single and only place to decide how an entry is formatted in the UI and how it is saved to file
b) make a bunch of explicit preferences options to decide how to format field names, entry types and so on

Consulting the BibTeX source to decide formatting wouldn't be the best option - the tail shouldn't be wagging the dog.

@github-project-automation github-project-automation bot moved this to Normal priority in Features & Enhancements Nov 20, 2023
@koppor koppor moved this from Normal priority to Low priority in Features & Enhancements Nov 20, 2023
@koppor koppor added this to the 6.0-beta milestone Jul 9, 2024
@koppor koppor self-assigned this Sep 5, 2024
@github-project-automation github-project-automation bot moved this to Normal priority in Prioritization Nov 13, 2024
@calixtus calixtus moved this from Normal priority to Low priority in Prioritization Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Low priority
Development

No branches or pull requests

3 participants