Language-specific CMS Metadata content is not being saved

[lgeggleston]

Describe the bug

When attempting to set content via "Edit CMS Metadata", Only the value entered in the "English" field is saved and displayed correctly. Input in all other language-specific fields is discarded or reset upon form submission. There is no error and saving appears successful, but nothing appears in the header for another language and if you return to the edit page the content has been discarded.

This remains true when tested with the site language set to match the one you enter CMS metadata for.

Reported from Testathon 2026 (T206) - Firefox and Chrome, DSpace 10.0

To Reproduce

Steps to reproduce the behavior:

1. Click 'Edit CMS metadata' in the sidebar, and select 'home-header'
2. Add content in the text box corresponding to any language besides English, and Save.
3. Return to the homepage, make sure your site is on the language you set content for, and nothing appears in the header. Open Edit CMS metadata again, and the text box you updated is empty.

Expected behavior

Content should save and display properly for any of the language text entries.

Related work

Related to Edit CMS feature
Related to #5339, though seems to be a different bug. It might be efficient to address both at the same time though.

[jesielviana]

I Observed behavior in the CMS metadata editor (/admin/edit-cms-metadata):

1. When filling a value for only one language, the PATCH request sends/generates metadata for all languages in the form, including empty entries.
2. Loading and displaying values depends on language mappings in webui.supported.locales.
3. The CMS metadata edit form loads only the selected/active language value, but it should load existing values for all available languages.
4. Region-specific locales (for example pt-BR, pt-PT) are not resolved correctly on read, because matching uses only the base language (for example pt) while metadata was saved with the full language tag (pt-BR, pt-PT).

---

Problem 1 — Persistence with Empty Metadata Entries

Symptom

When saving a CMS metadata field while filling only one language, the backend receives operations for multiple languages, and empty entries are persisted together with the valid value.

Impact

• Metadata pollution with empty values.
• Harder maintenance and troubleshooting for multilingual content.

Expected Fix

• Generate PATCH operations only for languages with non-empty values.
• If old values must be cleared, apply remove on the field and then add only for languages that were actually filled.

Fixed by PR: #5412

---

Problem 2 — Edit Form Loads Only Active Language

Symptom

When opening the CMS metadata editor, fields for other languages are not pre-filled with their existing database values; only the selected/active language appears with content.

Impact

• Gives the impression of data loss for other languages.
• Risk of overwriting multilingual content during editing.

Expected Fix

• On editor load, fetch metadata without locale filtering (all languages), so each form field is populated with its corresponding value.
• Keep the same behavior after save (reload object with all languages).

Fixed by PR: #5412

---

Problem 3 — Locale Resolution with Region (pt-BR / pt-PT)

Symptom

Even when metadata is saved as pt-BR or pt-PT, the value does not appear in the editor or display areas when locale resolution uses only pt.

Cause

On read, locale is often reduced to base language (for example context.getCurrentLocale().getLanguage() returns pt), while metadata is stored with the full language tag (for example pt-BR).

Impact

• Regional content is not found.
• User sees empty value or wrong fallback even though the value exists in the database.

Expected Fix

• Match full language tag first (pt-BR), with controlled fallback to base language (pt) only when appropriate.
• Ensure consistency between metadata language tag and the language used during query/display.
• Keep webui.supported.locales aligned with locales actually used in CMS metadata.