Add duotone and dimensions to the block level for translation

[oandregal]

Follow-up to #66675
Core backport at https://github.com/WordPress/wordpress-develop/pull/8031/files

What?

Make duotone and aspect ratios translatable to the block level (details).

Why?

Without this, the strings are not translatable.

How?

Adds duotone & aspect ratios under settings/blocks/*, so strings defined at these places are extracted for translation.

Testing Instructions

None. This will be picked by the wp-cli/i18n-command when merged in wordpress-develop.

[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: oandregal <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: swissspidy <[email protected]>

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

[swissspidy]

@oandregal I wonder, how can we prevent this (forgetting to make these strings translatable) from happening in the future? A CI workflow or lint script would be useful IMO.

[github-actions]

Flaky tests detected in f4d8ef2.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12466419429
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js
• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[oandregal]

I wonder, how can we prevent this (forgetting to make these strings translatable) from happening in the future? A CI workflow or lint script would be useful IMO.

Yeah, judging by the number of misses, I agree this is an area that needs to raise more awareness.

I'm happy to help with this, but I'm not sure how the lint would work, though. There are heuristics, but they are a bit weak: arrays present in settings within lib/theme.json? But there false positives. Or perhaps properties named name? But you can really name it anything you want. 🤔

[swissspidy]

Or maybe just some bot telling you to maybe update the schema file, just like it does for changelog files?

[oandregal]

Or maybe just some bot telling you to maybe update the schema file, just like it does for changelog files?

Oh, nice.

Could it work this way? Every change in theme.json will trigger the CI job and will fail if the new property added in theme.json is not in theme-i18n.json unless it has been added to a list of properties not to translate. We could bootstrap the initial list. It'd be even better if this was just part of the theme.json schema. cc @ajlende as it sounds something right up your alley :)

I'm not sure I'll have time to look at this before end of year given holidays, etc. but it sounds interesting!