Problem Summary
Currently, when lower levels of an archival unit include digital objects, the DO carousel will be shown - there is an example in the public demo site here.
This carousel currently comes with a hard-coded section header label that says "Image Carousel." However:
- This is inconsistent with the fact that elsewhere we regularly use "Digital object" as a more generic label
- Digital object is a customizable string in the user interface label settings, but this label is not
- Not all DOs in the carousel are necessarily images
Proposed enhancement
This issue proposes that "Image carousel" be added as its own user interface label setting. That way people can label it as appropriate for their content.
Alternatives considered
Using "Digital object carousel" as the default, and then making the "Digital object" part of that linked to the user interface label settings would be an acceptable, if slightly less customizable, enhancement.
Simply relabeling it as "Digital object carousel" would address some of the original inconsistencies but be far less useful, as it could not be changed. This would also add to the problems outlined in recently-filed issue #2336 however, and is therefore not recommended. The same is true for any other hard-coded labels.
Problem Summary
Currently, when lower levels of an archival unit include digital objects, the DO carousel will be shown - there is an example in the public demo site here.
This carousel currently comes with a hard-coded section header label that says "Image Carousel." However:
Proposed enhancement
This issue proposes that "Image carousel" be added as its own user interface label setting. That way people can label it as appropriate for their content.
Alternatives considered
Using "Digital object carousel" as the default, and then making the "Digital object" part of that linked to the user interface label settings would be an acceptable, if slightly less customizable, enhancement.
Simply relabeling it as "Digital object carousel" would address some of the original inconsistencies but be far less useful, as it could not be changed. This would also add to the problems outlined in recently-filed issue #2336 however, and is therefore not recommended. The same is true for any other hard-coded labels.