fix(i18n): add lowercase keys for selected search facets (#5048)

[JohnnyMendesC]

References

• Fixes Workflow search facet translation fails when selected due to case sensitivity mismatch #5048

Description

This PR fixes a bug where selected search facets (e.g., "Workspace", "Workflow", "Archived") displayed raw, untranslated values due to a case sensitivity mismatch between URL parameters (lowercase) and i18n keys (TitleCase).

It implements a code-based normalization strategy to force all facet lookups to lowercase, ensuring consistency between the sidebar list (Solr response) and selected filters (URL parameters), preventing regressions in boolean or other non-string filters.

Instructions for Reviewers

Context and Analysis:
The issue stems from inconsistent casing:

1. Unselected Facets (Sidebar): Values come from Solr/Discovery in TitleCase (e.g., "Workspace").
2. Selected Facets (Breadcrumbs/Filter tags): Values come directly from the URL parameter, which uses the internal ID in lowercase (e.g., f.namedresourcetype=workspace).

List of changes in this PR:

• Modified search-facet-option.component.html and search-facet-selected-option.component.html to apply the lowercase pipe to filter values.
• Imported LowerCasePipe in the corresponding standalone components.
• Renamed existing TitleCase keys (Workflow, Workspace) to lowercase in en.json5 and pt-BR.json5.

This PR implements a "lowercase normalization" strategy:

1. Code Change: Both the sidebar list (SearchFacetOptionComponent) and the selected filter breadcrumb (SearchFacetSelectedOptionComponent) now explicitly pipe the value to | lowercase before looking up the translation.
2. I18n Change: The existing TitleCase keys in en.json5 and pt-BR.json5 were renamed to lowercase to match the normalized lookup.

How to test:

1. Log in as an Administrator.
2. Navigate to /admin/workflow or /admin/search.
3. Filter by Status > Workspace (or "Área de trabalho").
   • Verify: The selected filter label should read "Workspace" (or translated equivalent like "Área de trabalho"), NOT "workspace".
4. Regression Test: Apply a boolean filter (e.g., Withdrawn > No or Non-discoverable > No).
   • Verify: The label should correctly display "No" (or "Não"), NOT "false".

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• 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.

[JohnnyMendesC]

@tdonohue I have refactored the code to implement the lowercase normalization strategy as discussed #5048 (using the | lowercase pipe in the components) and updated the translation keys in en.json5 and pt-BR.json5 to match. The PR has been reopened.

I have two questions regarding the next steps:

1. The "Archived" vs "item" discrepancy
I verified that standard facets (Workspace, Workflow) work correctly in both selected and unselected states. However, the Archived filter behaves differently:

• Sidebar: Uses the key ...namedresourcetype.archived.

• Selected (URL): The parameter is f.namedresourcetype=item, so it looks for ...namedresourcetype.item.

• pt-BR

• en

Currently, selecting "Archived" displays "item" because I haven't added the item key yet.

• Question: Should I add a duplicate key search.filters.namedresourcetype.item (mapped to "Archived") to en.json5 to fix this UI issue immediately? Or do you consider this a backend/separate issue that should be handled in a different PR?

---

2. Other Language Files
I only updated en.json5 and pt-BR.json5 to keep the PR clean.

• Question: Since I renamed the keys from TitleCase to lowercase, should I apply this renaming pattern to all other language files in this PR? Or is relying on the English fallback sufficient for now to avoid touching too many files?

[tdonohue]

@JohnnyMendesC : Based on your question, I was looking at how this behaves on sandbox.dspace.org and I've realized this is an existing bug (similar/related to the original ticket in this PR).

I can reproduce that same behavior on https://sandbox.dspace.org and doesn't appear to be caused by your PR, nor is it solved by this PR (yet).

That said, I think your solution is likely the correct one. It seems like there's a missing i18n key that should be added for

search.filters.namedresourcetype.item = Archived

I'm not sure why that key doesn't already exist.

Regarding updating all the other i18n files (besides en.json5 and pt-BR.json5): Because these changes are minimal (lowercasing 5 lines), I think it's reasonable to add those changes into this PR. It will make the PR slightly bigger, but it'd likely be super helpful to the translators out there (especially since it's such a simple fix). That said, if you'd rather not modify all these files, it's not a required changed -- we only require updates to the en.json5 file.

[JohnnyMendesC]

Thank you for taking the time to verify the item bug on the sandbox and for the clear guidance @tdonohue !

I have pushed two new commits to address both points:

1. Fixing the "item" bug: I added the missing search.filters.namedresourcetype.item key. To ensure a complete experience, I mirrored the respective "Archived" translation for this new key across all language files.
2. Global Lowercase Normalization: I went ahead and applied the lowercase normalization to all the namedresourcetype keys (workspace, workflow, archived, validation, and waiting for controller) across all *.json5 files, as you mentioned it would be super helpful for the translators.

The PR should be all set now and ready for a final review. Let me know if there's anything else needed!

[tdonohue]

@JohnnyMendesC : Just a brief note... this PR still has some minor lint failures that need cleanup. That's why there are test failures.

[JohnnyMendesC]

Thanks for the heads-up, @tdonohue!
I'm still getting used to the frontend tests and tools, and haven't noticed the lint error before.
I've just pushed a commit fixing the lint formatting issues on the imports of both .ts files. The checks are passing now.