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

Client-side validation only shows a message when a field is actually invalid at the moment you click Save. So each test below makes the field invalid on purpose. Use a literal (untranslated) validationtext string so it is obvious where the message comes from: Text::_() returns an unknown key unchanged.

The message is shown inside the field's label (a red span.form-control-feedback), not under the input. A red alert at the top of the page also says that the form can't be submitted.

Log in as a Super User so no field is disabled (disabled fields are skipped by the validator).

Test 1 – email field (most reliable)

1. Edit administrator/components/com_contact/forms/contact.xml and add a validationtext to the email_to field:

        <field
            name="email_to"
            type="email"
            label="JGLOBAL_EMAIL"
            validate="email"
            validationtext="Custom message: please enter a valid e-mail address"
        />

2. Go to Components → Contacts → New, fill in a Name, and go to the E-mail field (Edit Contact tab).
3. Inspect the E-mail input: it should have data-validation-text="Custom message: please enter a valid e-mail address".
4. Type not-an-email in the E-mail field and click Save.
5. The form is not submitted. The E-mail label shows "Custom message: please enter a valid e-mail address".

Test 2 – calendar field

1. Edit administrator/components/com_content/forms/article.xml and change the publish_up field. Adding required="true" is essential, because the core field is optional and an empty value would otherwise simply be valid:

        <field
            name="publish_up"
            type="calendar"
            label="COM_CONTENT_FIELD_PUBLISH_UP_LABEL"
            translateformat="true"
            showtime="true"
            filter="user_utc"
            required="true"
            validationtext="Custom message: a start publishing date is required"
        />

2. Go to Content → Articles → New, enter a Title, and open the Publishing tab.
3. Inspect the Start Publishing input: it should have the data-validation-text attribute and class="form-control required".
4. Make sure the field is empty (it is empty by default on a new article; on an existing article, open the calendar popup and click Clear). Then click Save while staying on the Publishing tab.
5. The form is not submitted. The Start Publishing label shows "Custom message: a start publishing date is required".

Test 3 – regression check for text

1. In the same article.xml, add validationtext="Custom message: title is required" to the title field (already required="true").
2. Content → Articles → New, leave Title empty and click Save.
3. The Title label shows "Custom message: title is required", exactly as before the patch.

Test 4 – explicit data-validation-text still wins

1. On the email_to field from test 1, also add data-validation-text="Explicit attribute wins".
2. Repeat test 1. The label shows "Explicit attribute wins", not the validationtext value.

Actual result BEFORE applying this Pull Request

• Test 1 and 2: the input has no data-validation-text attribute. On Save the label shows the generic message ("This value is not valid" for the e-mail, "Please fill in this field" for the calendar). The validationtext value is silently ignored. The same applies to every field type except text.
• Test 3: the custom message is shown.

Expected result AFTER applying this Pull Request

• Test 1 and 2: the input renders data-validation-text="…", and on Save the custom message is shown in the label.
• Test 3: unchanged, the custom message is shown.
• Test 4: the explicitly set data-validation-text is kept.

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