Determine consistent translation for inline field errors

[scottqueen-bixal]

Description

Due by: start of Sprint 37

Related to #1121

While adopting GSA Error handling we noticed two items,

1. There is a consistent format for handling inline error messages, "Fill out the {label} field"

2. There is an inconsistent format for handling inline error messages in the es locale, see https://www.usa.gov/es/funcionarios-electos#myStreetAddress

We would like to have a consistent structure and content for all locales

Option 1, lowest LOE
Recommend using similar structure to what we currently use in the Benefit Finder tool

en: Complete the {label} field
es: Responda el {label} campo

Option 2, higher LOE

• Include default consistent structure
• Include Drupal field that allows for string content to be customized an override default UI content if provided

User Story

As a developer I would like a consistent way of implementing inline error messaging that uses a {prefix}{label}{suffix} structure
As a user I would like to have clear directions on inline error messages
As a product owner, I expect to align well with the GSA error handling while still conforming to best practice, user experience, and technical implementation

Acceptance Criteria

• Option of decision is provided
• Default content is provided for both EN/ES

[diegocob]

Option 2 seems to work better for the longer-term and make it easier to read the error labels. In case we want to make other questions required, like, Fill out citizen status field vs Fill out Are you a U.S. citizen or eligible non-citizen field.

Since the field name in Spanish was in English, I created a translation in the content bank/criteria tab/column "I"

In English:
Fill out 'criteria title' field

In Spanish
Complete el campo de 'ES criteria title'
Note: In GSA's guide they used the word "escriba" (write) which is not accessible for people who don't write, or accurate since most people type, click or tap.

Would need to:

• Change all criteria names in Spanish
• Suggest also changing criteria names in English to simplify the
  • We discussed to take out the "applicant" and "deceased" from the criteria name
    • Applicant citizen status --> Citizen status

[scottqueen-bixal]

regarding this comment since, it doesn't align with the initial option 2 recommendation

Would need to:

 Change all criteria names in Spanish
 Suggest also changing criteria names in English to simplify the
We discussed to take out the "applicant" and "deceased" from the criteria name
Applicant citizen status --> Citizen status

We do not need to change all criteria names to manage customizations on error messaging.

we would likely only include a "custom error message" field, that would allow a content editor to provide a string value, in the case that the default messaging doesn't make sense

[diegocob]

We don't need to change all the fields' names and could opt to change only the ones currently required in a life event form.
However, if we make other questions required, for consistency and long-term sustainability, I suggest changing all field names, which is not a high LoE from the content side.

[scottqueen-bixal]

We don't need to change all the fields' names and could opt to change only the ones currently required in a life event form. However, if we make other questions required, for consistency and long-term sustainability, I suggest changing all field names, which is not a high LoE from the content side.

Criteria Title field is really just for back end CMS organization, not for UI display.

We have a sync this week set up to discuss in more detail. Rather than going back and forth here - let's hold off until after that meeting. Once we are all on the same page with acceptance criteria and the options described above, we will document decision here for implementation considerations.

[fongcindy]

• Diego will check with BF UX team to get confirmation on Spanish translation replacement for "escriba".
• Diego will check with usa.gov content team for approval.
• Scott can go ahead and make this change.

[scottqueen-bixal]

Option 2, higher LOE is preferred

Include default consistent structure
Include Drupal field that allows for string content to be customized an override default UI content if provided

• @diegocob to confirm on our recommended variation for ES, but need confirmation from USAgov

[diegocob]

I am checking with our UX and USAGov content teams about changing the "escriba" word.

Regarding the inconsistency of articles and names for the fields, the approach I suggested sounds grammatically incorrect.
Complete el campo [article ES field name]
Complete el campo de [la ciudad]
Complete el campo de[l código postal]

If we are creating a custom field for the error handling, I suggest adding the article to the error field name:
Complete el campo error handling name
Complete la dirección
Complete 'el codigo postal`

Would this work?

[scottqueen-bixal]

I am checking with our UX and USAGov content teams about changing the "escriba" word.

Regarding the inconsistency of articles and names for the fields, the approach I suggested sounds grammatically incorrect. Complete el campo [article ES field name] Complete el campo de [la ciudad] Complete el campo de[l código postal]

If we are creating a custom field for the error handling, I suggest adding the article to the error field name: Complete el campo error handling name Complete la dirección Complete 'el codigo postal`

Would this work?

We need a default that will handle most cases, you can customize whatever you want in the override field.

[diegocob]

This should work then.

[diegocob]

USAGov content (Shoshana) and design (Maria) teams approved using this for the Spanish inline error message:
Complete [error field name]

I will work on getting the error field messages for English and Spanish on another ticket.

[diegocob]

@scottqueen-bixal here's the inline error message doc

You can also find the inline error message in the inline error or criteria tab of the Content data bank

It's ready for boarding.

[diegocob]

The final error messaging text would be:
English:
Fill out the {EN_in-line_error} field

Spanish
Complete {ES_in-line_error}

[scottqueen-bixal]

The final error messaging text would be: English: Fill out the {EN_in-line_error} field

Spanish Complete {ES_in-line_error}

roger that, thanks @diegocob - will work on implementation