The release note body strings are hardcoded English instead of going through the translation bundle

Problem

Code/Translations covers the Live Data column labels and the applications panel entry. Every string on the page users actually read — the release note body — is hardcoded English.

Code/Change/ReleaseNotesChangesMacro: the three section headings (== For Users ==, == For Admins ==, == For Developers ==), the three submit labels (Add User Change, Add Admin Change, Add Developer Change), No changes! (x3) and === Miscellaneous === (x3).

Code/ReleaseNotesContributorsMacro: The following people have contributed code to this release (sorted alphabetically):, The list of contributors has not been generated yet. and Add contributors.

Form prompts: the withTip values in Code/HomeCustomReport (5), Code/HomeReleaseNotes and Code/HomeReleaseChanges.

XClass metadata: no field prettyName and no static-list value is translatable, in ChangeClass, EntryClass, ReleaseNoteClass, ContributorsClass or ReleaseNotesConfigClass — even where the field's own hint immediately above it already is a translation key. XWiki resolves Space.ApplicationClass_fieldName for the label and Space.ApplicationClass_fieldName_value for a list value, so the keys are available.

Consequence

Switching the wiki to another language leaves the release note fully English while its Live Data columns and the applications panel entry are translated. The L10N conventions call this out directly: it is worse to have a UI with pieces translated among many English words than a purely English one.

The Change edit form shows Target Audience and Importance plus their option lists in English, while the Live Data table above shows the same properties translated — the same field labelled two ways on two screens.

Notes when fixing

• The three No changes! occurrences need three keys, not one — the L10N conventions say not to reuse a key just because the string looks identical in two places.
• Submit buttons should be keyed <prefix>.submit; the withTip/placeholder prompts <prefix>.placeholder; field labels <prefix>.label.
• Compose each sentence as one key with parameters, never by concatenating a translated fragment with a value. Nothing in the module does this today, so it is a constraint on the fix rather than an existing defect.
• Code/HomeReleaseNotes has the one failure message of the primary flow, That release notes already exists! — ungrammatical, and it neither names nor links the release note that already exists. One key with the version as 0 would fix the wording and the i18n together.
• Code/Change/ChangeSheet re-declares its own labels rather than using the class prettyName}}s, and the wording drifts: {{Summary for the field whose prettyName is Short Description, Extra Description (optional) for Additional Description (Optional). Using the prettyName means the fix above covers the sheet too.

Scope

The existing gap is acknowledged in the repo's own guidance ("most button/message strings are still hardcoded English in the macros; new strings should go through the bundle"), so this issue is that debt written down with the specific sites, not a newly broken rule.