Improve descriptive labels for show/hide x more buttons for related items (Item/Entity Homepage)

[alisaismailati]

References

• Fixes [Deque Analysis] Item/Entity Homepage "serious" issues #1183

Description

Reference description in #1183 / Point 1

(ID 470327) "Purpose of the link is not clear in context." on the "Show 4 more" and "Hide last 4" links which appear in long lists of Entity relationships (especially on Person Entity pages like https://demo.dspace.org/entities/person/5a3f7c7a-d3df-419c-b8a2-f00ede62c60a).

Instructions for Reviewers

• Improves labels for "Show 4 more" and "Hide last 4" by making them more by adding also the label/entity it represents: E.g. “Show 4 more Organizational Units “.

• There will be no need for aria-label to be provided for simple basic buttons. They have an accessible name, the text itself: ARIA: button role - Accessibility | MDN
• A text-capitalize rule has been added to ensure that the first letter of each word is capitalized, eliminating the need to update each translation individually.
• Label will be translated based on the selected language. E.g. IT

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.