Support "name" attribute in `wp_register_webfonts`

[simison]

What problem does this address?

When registering fonts from a plugin with wp_register_webfonts, we define a font-family that then becomes the "name" of the font in Style picker.

When registering fonts with themes with theme.json, fontFamilies supports passing the name attribute that then gets picked by the UI as font label in the dropdown.

Using fontFamily as label works fine for most cases just fine. When a plugin provinding external font-provider (Google Fonts in our case), there isn't flexibility in pickign a nice font family name because the font family has to match the one passed to Google Fonts API.

For example, language-specific fonts in Google fonts don't have pretty names:

• Alexandria
• IBM Plex Sans Arabic
• Noto Sans Hebrew
• Noto Sans HK
• Noto Sans JP
• Noto Sans KR
• Noto Sans SC
• Noto Sans TC
• Noto Sans Telugu
• Noto Serif Hebrew
• Noto Serif HK
• Noto Serif JP
• Noto Serif KR
• Noto Serif SC
• Noto Serif TC

Above list would be better served with human-readable labels. It would be great to be able to translate the parts inside brackets, too.

	'Alexandria'           => 'Alexandria (Arabic)',
	'IBM Plex Sans Arabic' => 'IBM Plex Sans (Arabic)',
	'Noto Sans Hebrew'     => 'Noto Sans (Hebrew)',
	'Noto Sans HK'         => 'Noto Sans (Hong Kong)',
	'Noto Sans JP'         => 'Noto Sans (Japanese)',
	'Noto Sans KR'         => 'Noto Sans (Korean)',
	'Noto Sans SC'         => 'Noto Sans (Simplified Chinese)',
	'Noto Sans TC'         => 'Noto Sans (Traditional Chinese)',
	'Noto Sans Telugu'     => 'Noto Sans (Telugu)',
	'Noto Serif Hebrew'    => 'Noto Serif (Hebrew)',
	'Noto Serif HK'        => 'Noto Serif (Hong Kong)',
	'Noto Serif JP'        => 'Noto Serif (Japanese)',
	'Noto Serif KR'        => 'Noto Serif (Korean)',
	'Noto Serif SC'        => 'Noto Serif (Simplified Chinese)',
	'Noto Serif TC'        => 'Noto Serif (Traditional Chinese)',

What is your proposed solution?

wp_register_webfonts should support name attribute that then gets added to Theme JSON object.

AlternativelyI looked altering theme json object with wp_theme_json_data_theme filter (as in example) but this felt rather messy for something as simple.

[simison]

Not quite sure who could comment on this best and take a look at PR #46404 — @oandregal or @youknowriad you might know the best. :-)

[youknowriad]

Maybe that's a good one for @hellofromtonya as it relates to the fonts API.

[hellofromtonya]

The Web Fonts API's architecture is currently being completely redesigned (see #41481, #41484, #42868). I'll add this issue to its Roadmap but also block its PR until the architecture redesign PRs are merged.

[hellofromtonya]

This enhancement is now added to the Web Fonts API's Roadmap ✅ and the PR is blocked until the architectural work is merged ✅ .

[simison]

@hellofromtonya is it a good time to rebase this PR now that the API redesign is merged, or do you plan to continue refactoring the API?

[hellofromtonya]

@simison There are 2 more blocking architectural PRs, one of which will rename the entire API and all of its code. A status update is here #41479 (comment).

[hellofromtonya]

@simison This issue is now unblocked. Please note, the API has been completely redesigned including a brand new architecture and renamed to Fonts API (including all of the public function names).

[hellofromtonya]

Some notes to help:

• I closed PR Add name to wp_register_webfonts #46404. Why? Its implementation applied to the old API but will not work in the new Fonts API.
• A PR will be needed to add the "name" attribute.
• wp_register_webfonts() is now wp_register_fonts()
• The fonts definition array structure changed.
  Old:

array(
    array( /* font 1 */ ),
    array( /* font 2 */ ),
)

new array structure:

array(
    'Lato' => array(
          array( /* variation 1 */ ), 
          array( /* variation 2 */ ),
    ),
)

from an array of fonts to an array of font-families with each of the variations as an array to its keyed font-family.

The font-family key can be its proper name. The API will automatically convert it into a handle. Thus, a 'name' attribute might not be needed.