Upgrade StorageSemantic inconsistency in the distinction between Pages and # of Pages across Zotero localizations
Page position/range and total page count are two fundamentally different types of information. They therefore require two distinct fields with semantically distinct labels in every language. The current German localization obscures this distinction by translating both fields as "Seiten". At the same time, discussions in the English-language forum appear to distinguish these fields in their labels.
I believe this is one underlying semantic issue affecting the consistency of Zotero's data model and its localization across languages, rather than two unrelated translation problems.
Page count and page number are two distinct types of metadata and therefore require two separate fields with distinct labels — in every language.
I believe this is one underlying semantic issue affecting the consistency of Zotero's data model and its localization across languages, rather than two unrelated translation problems.
Page count and page number are two distinct types of metadata and therefore require two separate fields with distinct labels — in every language.
This discussion has been closed.
If you're referring to something else, provide a screenshot.
I think this misses the point. My concern is not how these values are distinguished in a CSL-formatted bibliography, but how users are expected to distinguish the corresponding fields in Zotero's metadata interface.
A user entering metadata should not have to rely on contextual conventions or knowledge of CSL to understand what a field represents. Page numbers/page ranges and total page counts are different kinds of information and should be identified by semantically distinct labels.
An interface should make the meaning of its fields clear in itself, rather than requiring users to learn additional conventions to compensate for ambiguous labels.
@dstillman
It may have had that label, but Zotero 10.0.7 does not.
And yes, I use AI for drafting and translation. I don't use it blindly, though. I check the wording and make sure it says what I actually want to say. Dismissing my post as "AI gibberish" is simply inappropriate.
The problem is very simple: When manually creating a parent item — in this case a newspaper article — I see the field label "Seiten" and have to wonder what exactly it means. Page numbers? A page range? The total number of pages?
There is another inconsistency: In the parent item, "Seiten" refers to the page number or page range within the publication. In the child item (the PDF attachment), the exact same label refers to the total number of pages in the PDF. The latter value is automatically determined by Zotero and cannot be edited.
These are two different kinds of information. Using exactly the same label for both is ambiguous and error-prone, regardless of whether the underlying distinction can be explained.
I shouldn't have to know anything about CSL or citation formatting to understand a metadata field.
The metadata field "# of Pages" ("Anzahl der Seiten" in the German locale) exists only on some item types — Book, Thesis, etc. It doesn't exist on Journal Article or Book Section.
"Pages" ("Seiten" in the German locale) means the page or page range, and that's what you'll see on Journal Article items and similar.
"Seiten" in the attachment pane isn't a metadata field — that's just non-editable file information like you'd see in any PDF reader. It's labeled "Pages" in English as well.
https://s3.amazonaws.com/zotero.org/images/forums/u16688703/omun239600hifthy15tq.png
I understand the distinction you're making between bibliographic metadata and attachment file information. But that distinction doesn't resolve the usability problem.
In the parent item, "Seiten" means the page number or page range within a publication. In the child item, the very same label, "Seiten", means the total number of pages in the attached PDF.
These are different concepts, displayed for different item types, but presented to the user with an identical label. Whether one is technically classified as bibliographic metadata and the other as file information makes no difference to the ambiguity.
A label should retain its meaning throughout the user interface. If the meaning changes, the label must change accordingly. This should be a basic consistency rule, not something users are expected to learn their way around.
I think your last paragraph illustrates precisely the difference in our approaches to usability.
You consider it acceptable that users will learn to distinguish two different meanings of "Pages" through experience, by encountering different item types. I consider this an unnecessary obstacle.
A user should not have to build up a collection of different item types before being able to understand what a visible label means. Nor should familiarity with reference managers or BibTeX be a prerequisite for using Zotero intuitively.
You acknowledge that "Page Count" would be a possible label for the attachment information, but consider the change unnecessary. I disagree. It would make the interface more explicit, consistent and less error-prone.
The fact that one value is bibliographic metadata and the other is automatically retrieved file information is relevant to the internal data model. It does not justify presenting two different concepts under the same label.
This is not about teaching users how Zotero works. It is about making Zotero understandable without requiring that knowledge in the first place.
"Page Number" and "Page Count" would be the obvious, user-friendly solution. Whatever Zotero needs to do behind the scenes to handle these values should be hidden from the user. Exposing internal distinctions that are counterintuitive and unnecessary for the user's task only makes the interface harder to understand.
Bücher, z.B., haben #of Pages/Anzahl der Seiten für die Zahl der Seiten und dafür kein "Seiten/Pages" feld.
Das mit dem Dateianhang kannst Du gerne so sehen, aber dstillman (und ich) sind hier täglich seit fast 20 Jahren und es stimmt einfach nicht, dass das zur Verwirrung führt.