Pull Request resolves #48416.

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

FormField::getLayoutData() already exposes $validationtext (populated from the XML validationtext attribute) to every field layout under layouts/joomla/form/field/. But of the 36 files there, only text.php actually turns it into the data-validation-text HTML attribute that validate.es6.js's markInvalid() reads for the client-side "invalid" message — and even there it is marked // @TODO add a proper string here!!!. checkbox.php documents $validationtext in its docblock but never uses it. Every other field type — including several that already build their own pattern attribute for HTML5 validation (tel, date, datetime, email, url, number, ...) — has no reference to it at all.

This PR moves the translate-and-output step into FormField::renderDataAttributes(), the shared method that builds $dataAttribute and is already echoed by essentially every field layout. That makes validationtext work consistently for all field types from one place, with consistent escaping: the current text.php uses $this->escape(), while several other layouts build their data attributes via ArrayHelper::toString(), which does not escape at all. renderDataAttributes() already uses htmlspecialchars(), so centralizing here avoids that inconsistency.

The now-redundant line in text.php is removed, which also resolves its @TODO.

Backward compatibility: a field that already sets a literal data-validation-text="..." XML attribute is unaffected — the new code only fills the key when it is not already present.

Testing Instructions

1. Apply the patch.
2. Edit any form XML that uses a non-text field type and add a validationtext attribute, for example a calendar field in administrator/components/com_content/forms/article.xml:

       <field
           name="publish_up"
           type="calendar"
           label="COM_CONTENT_FIELD_PUBLISH_UP_LABEL"
           translateformat="true"
           showtime="true"
           filter="user_utc"
           required="true"
           validationtext="JLIB_FORM_FIELD_INVALID"
       />

3. Open that form in the administrator (Content → Articles → New).
4. Inspect the calendar input in the browser dev tools and check for a data-validation-text attribute.
5. Clear the field so it fails validation and submit the form. Observe the message shown next to the field.
6. Repeat with a text field that has validationtext set to confirm nothing regressed there.

Actual result BEFORE applying this Pull Request

The calendar field renders without the attribute:

       <input type="text" ... class="form-control" required>

On failed validation the field falls back to the generic invalid message; the value of validationtext is silently ignored. The same applies to every field type except text.

Expected result AFTER applying this Pull Request

The calendar field renders the translated attribute:

       <input type="text" ... data-validation-text="Invalid field:" class="form-control" required>

On failed validation markInvalid() picks it up and shows the translated validationtext as the message. text fields behave exactly as before, and fields that set data-validation-text explicitly in their XML keep their own value.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed