Moved Journal Abbreviation from Quality Menu to Cleanup Entries Dialog

[GDeane]

Closes #11791 This change moves the Journal Abbreviation behavior from the Quality Menu into the Cleanup Entries Dialog as follows:

The JabRef documentation will need to be updated. A new issue has been created to do this here

Before Changes

After Changes

Summary

This pull request implements the steps outlined in this issue refinement

Specifically, all journal‐abbreviation tasks (both abbreviate and unabbreviate) from separate menu commands have been moved into the “Clean up entries” dialog. This allows the user to pick how they want to handle journal names—no change, abbreviate, or unabbreviate—directly inside the Cleanup dialog rather than from separate menu items.

Key changes:

• Journal‐related combo box in the Cleanup dialog. You can choose:
  1. No changes (default)
  2. Abbreviate (default)
  3. Abbreviate (dotless)
  4. Abbreviate (shortest unique)
  5. Unabbreviate
• Added two new cleanup classes:
  • AbbreviateJournalCleanup (replaces old UndoableAbbreviator)
  • UnabbreviateJournalCleanup (replaces old UndoableUnabbreviator)
• Removed the old "Abbreviate" and "Unabbreviate" items from the Quality menu, as well as old references in the code to UndoableAbbreviator, UndoableUnabbreviator, and the old keybindings for them.
• Added tests in AbbreviateJournalCleanupTest and UnabbreviateJournalCleanupTest, along with changes to JournalAbbreviationRepositoryTest so the coverage is the same as before but uses the new cleanup approach.

Notable Design Details

To perform this change, the functionality in UndoableAbbreviator (and UndoableUnabbreviator) had to be adapted to the org.jabref.logic.cleanup.CleanupJob interface. I discovered while figuring out an implementation that org.jabref.logic.cleanup.AbbreviateJournalCleanup (and org.jabref.logic.cleanup.AbbreviateJournalCleanup) both needed access to a JournalAbbreviationRepository object. Many of the changes in this PR are related to this dependency being passed down from org.jabref.gui.frame.MainMenu and org.jabref.gui.frame.MainToolBar. This issue is further described at this comment and this comment

It was suggested here that the journal abbreviation menu items instead be added to the field formatters in the UI, and implemented as a Formatter. The reason this was not done is because all the formatters act as stateless transformations, and are instantiated without any parameters (see org.jabref.logic.formatter.Formatters). Journal Abbreviation is notably not stateless, as it needs access to JournalAbbreviationRepository. Theoretically, this could be overcome with dependency injection into the logic layer, but I believe that violates the architecture.

How To Test

IMPORTANT NOTE: When testing and switching from running JabRef on this branch to running JabRef on the main branch, I had an unhandled exception because a new enum constant (e.g. UNABBREVIATE) persisted in the user preferences, but the code on main doesn't define this constant:

The only workaround I have found for this is to go in JabRef to File -> Preferences -> Reset Preferences and then hit save.

1. Open the “Clean up entries” dialog (Quality → “Clean up entries”).
2. Select a group of entries with different journal names.
3. In “Journal‐related,” pick Abbreviate (default) or Unabbreviate, then apply cleanup.
4. Observe that the journal fields have become either abbreviated or unabbreviated accordingly.
5. If you open the Cleanup dialog again, your choice in the combo box should persist in subsequent sessions (provided you store your preferences).

Additionally:

• Try “Abbreviate (dotless)” or “Abbreviate (shortest unique)” on a few entries with known abbreviations (like “Physical Review Letters” → “PRL”).
• Run the tests at org.jabref.logic.cleanup.AbbreviateJournalCleanupTest, org.jabref.logic.cleanup.UnabbreviateJournalCleanupTest, and org.jabref.logic.journals.JournalAbbreviationRepositoryTest

Mandatory checks

• [x] I own the copyright of the code submitted and I license it under the MIT license
• [x] Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• [x] Tests created for changes (if applicable)
• [x] Manually tested changed features in running JabRef (always required)
• [x] Screenshots added in PR description (if change is visible to the user)
• [x] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• [x] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[GDeane]

I thought I should address the 30+ trag-bot comments before making it a non-draft PR. Haven't had time yet but I'll get it done by this weekend.

[koppor]

I thought I should address the 30+ trag-bot comments before making it a non-draft PR. Haven't had time yet but I'll get it done by this weekend.

Yeah. However, the functionality can be tried out and the main code can also be checked. If some maintainer has time @tobiasdiez maybe?

[GDeane]

This is kind of concerning. I don't know why it's taking 50 minutes:

I did close some of its comments which I judged invalid as they popped up. I dunno if that caused this

[koppor]

This refs https://github.com/JabRef/jabref/issues/11305#issuecomment-2418468451

[trag-bot[bot]]

@trag-bot didn't find any issues in the code! ✅✨

[zikunz]

I have been studying this PR as part of preparing my GSoC proposal for the multi-list journal abbreviation management feature. Moving abbreviation functionality to the Cleanup dialog makes a lot of sense for workflow simplification!

My proposed implementation would extend this approach by allowing users to select which specific abbreviation lists are active, while maintaining the clean interface you've designed here. I would appreciate any thoughts on how you see these features working together.

cc @koppor

[GDeane]

I have been studying this PR as part of preparing my GSoC proposal for the multi-list journal abbreviation management feature. Moving abbreviation functionality to the Cleanup dialog makes a lot of sense for workflow simplification!

My proposed implementation would extend this approach by allowing users to select which specific abbreviation lists are active, while maintaining the clean interface you've designed here. I would appreciate any thoughts on how you see these features working together.

I'm not sure exactly what you mean by multi-list journal abbreviation management feature. What I can say is that this change was implemented without any modification to the JournalAbbreviationRepository class (responsible for maintaining the lists of journal abbreviations).

That is, this change moved the journal abbreviation feature from the Quality menu to the Clean up entries dialog (and made the abbreviations run as a CleanupJob like everything else in the Clean up entries dialog), but did not change the way those lists were used.

I don't think this PR conflicts with what you're suggesting. What I'd like to know is whether this multi-list journal abbreviation management feature would go in the settings menu or also somehow fit in the Cleanup entries dialog.

[GDeane]

How many different abbreviation lists does the average user have?

How often do they want to change between them?

Is an abbreviation list tied to the specific bibliography the user has open or not?

These are questions I did not have to answer for the PR I created, but sound like they would be worth asking/answering for what you're propoosing.

[Siedlerchr]

Please resolve the merge conflicts

[zikunz]

@GDeane #12364 is what I meant by multi-list journal abbreviation management feature.

Thank you so much for sharing the valuable information. I did not suggest there is a conflict but I believe understanding this PR is required to implement changes to close #12364. Thanks!

[koppor]

How many different abbreviation lists does the average user have?

Multiple - maybe 2: ACM, IEEE for computer science. You can check the lists at https://github.com/JabRef/abbrv.jabref.org/tree/main/journals and guess which are related in a field. Maybe, IEEE is used by all natural sciences maybe?

Idea is that a group of researchers could have their own list in addition to some "official" one - maybe "harvested" from an external sercie (such as MathSciNet)

How often do they want to change between them?

Very seldom.

Is an abbreviation list tied to the specific bibliography the user has open or not?

Possibly yes - but much work to do.

[koppor]

@GDeane We are very sorry that there are these much conflicts. May I ask if you can find some time to address them?

[colinseifert]

@GDeane We are very sorry that there are these much conflicts. May I ask if you can find some time to address them?

I will try and resolve these shortly.

[GDeane]

@colinseifert a note that the conflicts are the result of issue #12880 being implemented (Add support for LTWA).

What this means for this PR is that we will have to integrate this new abbreviation option into this differing interface.

Make sure you take a look at issue #12880 and the changes made to implemented before fixing any conflicts.

[subhramit]

Hi, would you guys be able to resolve the merge conflicts? (apologies for them, we were working on a multi-project build).

Steps to adapt your branch to the new project structure and resolve most conflicts are outlined here.

If you are unable to join, I quote the text here:

You need to do a gradle sync Do a git merge using the commandline. git fetch upstream git merge upstream/main Then, most conflicts should be resoled automatically. For the others, use the conflict resolution feature of IntelliJ And do a git submodule update

(Let us know if you need more help).