JCU/fix(i18n-cs): drop unresolvable {{ collection }} from browse.title

[Kasinhou]

Fixes the first item reported in dataquest-dev/dspace-customers#853.

Problem

On the Czech UI, /browse/srsc?startsWith=deferred%20tax renders the placeholder literally:

Procházet {{ collection }} podle Subject Category

Reproduced on the JCU test instance (dev-6.pc:8593, Czech UI) and visible in the reporter's
production screenshot in the issue.

Cause

The Czech translation of browse.title carries a {{ collection }} interpolation parameter that
the English source message does not have:

en.json5  "browse.title": "Browsing by {{ field }}{{ startsWith }} {{ value }}"
cs.json5  "browse.title": "Procházet {{ collection }} podle {{ field }}{{ startsWith }} {{ value }}"

Neither call site passes such a parameter — both pass exactly field, startsWith, value:

• src/app/browse-by/browse-by-metadata/browse-by-metadata.component.html
• src/app/browse-by/browse-by-taxonomy/browse-by-taxonomy.component.html (this is /browse/srsc)

ngx-translate leaves an unmatched parameter untouched, so the user sees the raw {{ collection }}.

The key was already flagged in cs.json5 with // TODO Source message changed - Revise the translation: upstream dropped {{ collection }} from the English message, and the Czech
translation was never revised. It is revised now, so the TODO marker goes too.

Fix

One line in src/assets/i18n/cs.json5:

- // TODO Source message changed - Revise the translation
- "browse.title": "Procházet {{ collection }} podle {{ field }}{{ startsWith }} {{ value }}",
+ "browse.title": "Procházet podle {{ field }}{{ startsWith }} {{ value }}",

The wording now matches the neighbouring browse.title.page key, which already reads
"Procházet podle {{ field }} {{ value }}".

Whole-bundle audit

Rather than fix only the reported key, every key in cs.json5 was compared against en.json5 for
interpolation mismatches (placeholders present in one and not the other). browse.title was the
only user-visible offender. Two further findings are deliberately left alone:

Key	Finding	Why not fixed here
admin.access-control.epeople.notification.deleted.failure	CS uses {{name}}, EN uses {{id}}/{{statusCode}}/{{restResponse.errorMessage}}	The key is orphaned — no component renders it. epeople-registry.component.ts:251 mistakenly reuses notification.deleted.success for the error branch. That is a separate upstream FE bug, not a translation bug.
deny-request-copy.email.message	CS drops {{ recipientName }}, so the outgoing email has no salutation	Restoring it means choosing Czech wording with gender agreement on a person's name. That is a content decision for JCU, not a rendering defect.

Verification

Same page, same locale, before and after.

Before — JCU test instance dev-6.pc:8593, Czech UI

Before — local UI on this branch's parent (customer/jcu)

After — local UI on this branch

Note that Subject Category in the heading stays English in the "after" shot. That is a different
untranslated key (browse.metadata.srsc) tracked separately as M5 in the #853 checklist, and is
intentionally out of scope here.

Also checked in the same locale, before and after: /browse/subject, /browse/title,
/browse/author, /browse/dateissued — no other browse heading regressed, and the English UI is
untouched (only cs.json5 changed).

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the Czech (cs) i18n bundle to remove an unresolvable {{ collection }} placeholder from the browse.title translation so browse headings no longer render the raw interpolation token in the UI.

Changes:

• Removed the stale {{ collection }} interpolation from browse.title in cs.json5.
• Dropped the associated “TODO Source message changed” marker now that the translation matches the source placeholder set.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.