|
| 1 | +--- |
| 2 | +title: Hardcode `StandardField` names and use exact or customized names otherwise |
| 3 | +nav_order: 49 |
| 4 | +parent: Decision Records |
| 5 | +status: accepted |
| 6 | +date: 2025-09-13 |
| 7 | +--- |
| 8 | +<!-- markdownlint-disable-next-line MD025 --> |
| 9 | +# Hardcode `StandardField` names and use exact or customized names otherwise (disallow customization of `StandardField`s) |
| 10 | + |
| 11 | +## Context and Problem Statement |
| 12 | + |
| 13 | +JabRef allows users to define custom fields and customizing `StandardField`s with arbitrary names and arbitrary casing. Users reported inconsistent casing of field names across the tabs in the details panes of the entry editor (Required/Optional/Other fields), within saved BibTeX files and preferences. |
| 14 | +Fields were partially forced to show in UI with a capital first letter by a UI method inside the `Field` model. |
| 15 | +A argument was made in issue [#116](https://github.com/JabRef/jabref/issues/116) about how to case the field names in the `.bib` file. It was then decided to always lowercase the field names, as BibTeX itself is case-insensitive in that matter, but convention in bibtex style is to lowercase it. |
| 16 | +There were complains, that this inconsistency [confuses users](https://github.com/JabRef/jabref/issues/10590) and makes it impossible to achieve a predictable, uniform presentation between UI and persisted data, especially when dealing with customized fields. |
| 17 | + |
| 18 | +How should JabRef consistently determine the casing for field names in UI and persistence for both built‑in and custom fields? |
| 19 | + |
| 20 | +## Decision Drivers |
| 21 | + |
| 22 | +* Consistent user experience across all UI locations |
| 23 | +* Predictable persistence and round‑trip stability (UI ↔ preferences ↔ `.bib`) |
| 24 | +* Backward compatibility with existing libraries and preferences |
| 25 | +* Internationalization (i18n) and localization concerns for built‑in fields |
| 26 | +* Minimal complexity added to parsing/serialization logic |
| 27 | +* Avoid breaking community conventions for BibTeX/BibLaTeX (lowercase keys in files) |
| 28 | +* Avoid mixed casing rules per UI location |
| 29 | +* Minimize changes to bib files |
| 30 | +* Respect the choice of the user for casing of custom fields |
| 31 | + |
| 32 | +## Considered Options |
| 33 | + |
| 34 | +* Hardcode `StandardField` names and use exact or customized names otherwise (disallow customization of `StandardField`s) |
| 35 | +* Make all field names (including `StandardField`s) fully user‑configurable for display casing across UI and persistence |
| 36 | +* Normalize all field names to lowercase everywhere (UI, preferences, `.bib`) |
| 37 | +* Normalize all field names to title case in UI and in preferences; lowercase in `.bib` |
| 38 | + |
| 39 | +## Decision Outcome |
| 40 | + |
| 41 | +Chosen option: "Hardcode `StandardField` names and use exact or customized names otherwise," because |
| 42 | + |
| 43 | +* Aligns with community conventions (lowercase keys in `.bib`), ensuring compatibility. |
| 44 | +* Provides a consistent and localized UI for built‑ins by using canonical, hardcoded display labels. |
| 45 | +* Respects users’ expectations for custom fields by preserving the casing they define everywhere in the UI and in preferences. |
| 46 | +* Minimizes behavioral surprises and avoids mixed casing rules per UI location. |
| 47 | + |
| 48 | +## Pros and Cons of the Options |
| 49 | + |
| 50 | +<!-- markdownlint-disable-next-line MD024 --> |
| 51 | +### Hardcode `StandardField` names and use exact or customized names otherwise (disallow customization of `StandardField`s) |
| 52 | + |
| 53 | +<!-- markdownlint-disable-next-line MD004 -->> |
| 54 | +- For the build-in types (`StandardField`), the display names are hard-coded. Users cannot customize this. Optional/required can still be customized. |
| 55 | +<!-- markdownlint-disable-next-line MD004 -->> |
| 56 | +- Preserve exact user/customized names for non‑standard fields |
| 57 | +<!-- markdownlint-disable-next-line MD004 -->> |
| 58 | +- Serialize as customized (and lower-case as standard) to `.bib` file |
| 59 | + |
| 60 | +* Good, because round‑trip: UI labels ↔ preferences ↔ UI remain stable. |
| 61 | +* Good, because built‑in labels can be localized predictably (title case or localized form). |
| 62 | +* Good, because consistent casing across entry editor tabs. |
| 63 | +* Good, because matches BibTeX convention for stored keys. |
| 64 | +* Good, because supports localization of displaying of `StandardField` names. |
| 65 | +* Good, because `.bib` files keep canonical lowercase keys in the default case. This matches common BibTeX/BibLaTeX practice. |
| 66 | +* Good, because decouples model (internal key) from UI (display label). |
| 67 | +* Bad, because users cannot change casing of built‑in field display names by using the entry customization. |
| 68 | +* Bad, because perceived as inconsistent at [#10590](https://github.com/JabRef/jabref/issues/10590). |
| 69 | +* Bad, because requires a clear separation of internal key vs. display label, which slightly increases conceptual complexity. |
| 70 | +* Bad, because migration needs to ensure older preferences do not inadvertently force lowercasing of custom fields in UI. |
| 71 | + |
| 72 | +### Make all fields fully user‑configurable |
| 73 | + |
| 74 | +This is option "Hardcode `StandardField` names and use exact or customized names otherwise (disallow customization of `StandardField`s)" with allowing customization of `StandardField`s. |
| 75 | + |
| 76 | +* Good, because provides maximum flexibility for users: Users can change casing of built‑in field display names by using the entry customization. |
| 77 | +* Good, because perceived as consistent at [#10590](https://github.com/JabRef/jabref/issues/10590). |
| 78 | +* Bad, because increases settings complexity and risk of inconsistent UI and preferences. |
| 79 | +* Bad, because harder to localize built‑ins; can lead to team‑specific divergences. |
| 80 | + |
| 81 | +### Normalize all field names to lowercase everywhere (UI, preferences, `.bib`) |
| 82 | + |
| 83 | +* Good, because simplest to implement; fully consistent. |
| 84 | +* Bad, because Poor UX; clashes with common expectations for UI labels. |
| 85 | +* Bad, because Undermines localization and readability. |
| 86 | + |
| 87 | +### Normalize all field names to title case in UI and in preferences; lowercase in `.bib` |
| 88 | + |
| 89 | +* Good, because UI looks consistent and readable. |
| 90 | +* Bad, because ignores user intent for custom fields’ casing (less flexibility). |
| 91 | +* Bad, because preferences may mask underlying canonical keys, complicating tooling. |
0 commit comments