-
Notifications
You must be signed in to change notification settings - Fork 447
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
DSpace#1306 - Implementation that makes it possible to customize thum… #2783
DSpace#1306 - Implementation that makes it possible to customize thum… #2783
Conversation
…descriptions of items, collections and communities
…descriptions of items, collections and communities
@@ -34,6 +34,11 @@ export const collectionFormModels: DynamicFormControlModel[] = [ | |||
name: 'dc.description.abstract', | |||
spellCheck: environment.form.spellCheck, | |||
}), | |||
new DynamicTextAreaModel({ | |||
id: 'thumbnail', | |||
name: 'dc.description.thumbnail', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DanGastardelli : This dc.description.thumbnail
field isn't a valid Qualified Dublin Core field, so I would not recommend adding it. Additionally, this is metadata about the Bitstream (logo), but you appear to be storing this metadata on the Collection.
It's not a great idea to store this on the Collection, as it means that this dc.description.thumbnail
field would be shared as Collection description metadata whenever someone accesses the Collection from the REST API (or other machine interfaces like OAI-PMH).
Ideally, it'd be better to store this metadata as simply dc.description
(which already exists) on the Bitstream object itself. That'd be much clearer & cleaner than creating a new metadata field to store the information on the Collection.
If it's not possible or easy to store this metadata on the Bitstream itself, then we could consider keeping this metadata on the Collection, but store it in a "hidden" field like dspace.thumbnail.description
. This would be better than creating an invalid dc.description
field. But, this new field would need to be created though in the dspace/config/registries/dspace-types.xml
on the backend.
Hi @DanGastardelli, |
…bnail descriptions of items, collections and communities
References
Fixes #1306
This change was aimed at #1306 which now allows a detailed description of the thumbnail logo images of items, collections and communities (also recognized by screen readers).
Description
First, logic was created using OnInit in the thumbnail component to bring the value of the thumbnail description to the "alt" text contained in the image tag in the html. Fields were then created for insertion in the creation and editing of communities and collections that allowed the insertion of details about the logos involved and finally the creation of translation keys for these fields.
Instructions for reviewers
First of all, it is necessary to create the "dc.description.thumbnail" metadata in the backend where the test is carried out.
List of changes in this PR:
Include guidance on how to test or review your PR.
To test, simply create a collection and community that contains a logo. In the "Thumbnail Description" field, fill in details of this logo and finally inspect the logo or use a screen reader on the logo to validate the description entered. Now as for the items, just insert a bitstream and create the thumb by running filter-media in the backend. After that, go to item editing and go to the bitstream tab and edit the thumbnail description and then go to the item and hover the screen reader over the image or inspect it to see if the description matches the one entered.