Font size picker: Fix i10n and a11y for HeaderLabel

[im3dabasia]

Closes: #63810

What?

• This PR refactors the font-size-picker component to improve the translation in the HeaderLabel. It ensures that text concatenation issues are resolved for gendered languages (e.g., Italian).
• There is an aria-label in the HeaderLabel component, which renders a <span>. Since this element is non-interactive and purely for display purposes, having an aria-label here does not make sense, as it would be ignored by screen readers.

Why?

Currently, the font-size-picker renders text by concatenating strings (e.g., "Size " + headerHint), which makes translation inaccurate for languages with gendered nouns. For example, in Italian, the noun 'Size' is translated to the feminine form "Dimensione," but concatenating it with size adjectives (which are masculine) results in incorrect translations like "Dimensione piccolo" (incorrect).

How?

• Refactored the HeaderLabel component to use createInterpolateElement for proper translation of Size and headerHint.
• Removed the aria-label in the HeaderLabel.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: im3dabasia <im3dabasia1@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[im3dabasia]

@afercia , Thank you for creating the issue #63810

I have drafted a possible solution and would appreciate any feedback. I took inspiration from here. Let me know if this works for our case.

Code

gutenberg/packages/block-editor/src/components/date-format-picker/index.js

Lines 144 to 167 in 5704f91

	{ isCustom && (
	<TextControl
	__next40pxDefaultSize
	__nextHasNoMarginBottom
	label={ __( 'Custom format' ) }
	hideLabelFromVision
	help={ createInterpolateElement(
	__(
	'Enter a date or time <Link>format string</Link>.'
	),
	{
	Link: (
	<ExternalLink
	href={ __(
	'https://wordpress.org/documentation/article/customize-date-and-time-format/'
	) }
	/>
	),
	}
	) }
	value={ format }
	onChange={ ( value ) => onChange( value ) }
	/>
	) }

[afercia]

Using createInterpolateElement is certainly better than concatenation but it still doesn't solve the translation problem. headerHint retunrs the 't-shirt names' that are just appended to the first part of the string Size.

https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/font-size-picker/constants.ts/#L31-L37

As the t-shirt names are translated separately they can't be conjugate correctly with the gender of the noun Size. The only way to solve this for all languages is by providing fully translatable strings. e.g.:

__( 'Size Small' ),
__( 'Size Medium' ),
__( 'Size Large' ),
__( 'Size Extra Large' ),
__( 'Size Extra Extra Large' ),

The strings may contain HTML or placeholder for some HTML to preserve the intende design but I'd consider that minor. The implementation should be changed accordingly in order to use the full strings.

[t-hamano]

The headerHint text may be changed by theme.json. Example:

Details

{
	"version": 3,
	"settings": {
		"typography": {
			"defaultFontSizes": false,
			"fontSizes": [
				{
					"name": "Custom small",
					"size": "14px",
					"slug": "small"
				},
				{
					"name": "Custom medium",
					"size": "16px",
					"slug": "medium"
				}
			]
		}
	}
}

Therefore, I think it is impossible to provide fully translatable text with the current implementation. In this PR, I would like to avoid making major changes to the design and implementation and propose an approach using createInterpolateElement.

[afercia]

I'm not sure refraining from reconsidering design and implementation helps building a better UI. Design should prioritize functionality and follow the best practices established in WordPress. Otherwise it's not design. The implementation is unnecessary comples and inconsistent at the point I'm considering to propose to entirely remove the headerHint. Will detail on the issue.

[afercia]

Also, the fact headerHint displays the font size names provided by the theme may potentially make it display inappropriate strings as the names quality and length is unpredictable. It could really be anything, totally uncontrolled. Screenshot:

[t-hamano]

Design should prioritize functionality and follow the best practices established in WordPress.

Can you tell us what you think is the best approach to take with this PR?

the fact headerHint displays the font size names provided by the theme may potentially make it display inappropriate strings as the names quality and length is unpredictable. It could really be anything, totally uncontrolled.

This issue is discussed here: #68344

[afercia]

Can you tell us what you think is the best approach to take with this PR?

I'm considering to propose to entirely remove headerHint. See #63810 (comment)

[t-hamano]

If we delete headerHint, how will users know about the custom labels? Without custom labels, users may not understand the meaning of the font sizes the theme provides.