Block Editor: UI message keys do not match the behavior they describe

Problem Statement

Several message keys in the Block Editor UI (libs/new-block-editor) carry copy that does not describe what the control actually does. The label text and the underlying behavior have drifted apart, so content authors are told one thing and get another.

Confirmed example — image properties dialog:

dotCMS/src/main/webapp/WEB-INF/messages/Language.properties:6516

dot.block.editor.dialog.image-properties.field.tooltip.placeholder=Add a caption…

That placeholder sits on an input bound to form.controls.title in image-popover.component.html. The title attribute is the browser tooltip, not a caption — and the sibling keys confirm it:

Impact: Content authors type caption text into a field that renders as a hover tooltip. The text never appears on the page, and there is no visible error — the author simply believes the caption is set. This will get worse once a real Caption field ships (#37496), because two fields will appear to do the same thing.

The image dialog is the one instance we have verified. This defect covers auditing the whole Block Editor UI for the same class of mismatch and fixing every instance found.

Browser & OS: not browser-specific — the copy is wrong in all browsers.

Steps to Reproduce

1. Log in to the dotCMS admin and edit a contentlet that has a Block Editor field.
2. Insert an image into the Block Editor (toolbar → Insert image, or the slash menu).
3. Select the image, then click Edit image properties in the image toolbar.
4. Look at the second field, labeled Tooltip.
5. Observe the placeholder text reads "Add a caption…".
6. Type text into that field and click Save.
7. Publish/preview the page.
8. Expected: the text appears as a caption below the image, as the placeholder promised.
9. Actual: the text is written to the <img title="…"> attribute and only appears as a hover tooltip. No caption is rendered anywhere.

Acceptance Criteria

Audit

• Every dot.block.editor.* key used by libs/new-block-editor is reviewed against the control it is bound to and the behavior that control triggers
• The audit covers labels, hints, placeholders, aria-labels, tooltips, toolbar item text, slash-menu entries, and dialog titles
• The audit findings are recorded as a comment on this issue — one line per mismatch, giving the key, the current value, the actual behavior, and the corrected value
• Every key referenced from libs/new-block-editor templates and TypeScript resolves to an existing entry in Language.properties (no missing keys rendering as raw key strings)
• Every dot.block.editor.* entry in Language.properties is still referenced by libs/new-block-editor (orphaned keys are reported, not silently removed)

Confirmed fix

• dot.block.editor.dialog.image-properties.field.tooltip.placeholder no longer mentions "caption" and describes tooltip text instead
• The Tooltip field's label, hint, and placeholder all consistently describe the browser tooltip behavior

Remaining fixes

• Every mismatch found in the audit is corrected in Language.properties
• No message key is renamed unless its current name is itself misleading; where a rename is required, all references are updated in the same change

No regressions

• Every corrected key still renders through the | dm pipe with no missing-key fallbacks in the UI
• aria-label corrections keep every interactive control in the Block Editor labeled for screen readers

Tests

• Unit specs in libs/new-block-editor/ assert the corrected keys are the ones bound to their respective controls

dotCMS Version

Latest from main (verified at commit 66bb905280).

Severity

Low - Minor issue or cosmetic

Links

• NA — no Freshdesk ticket. Found during Block Editor development.