Repository navigation
Apply typographic transformations (texturize) to DataForm field labels and descriptions #77056
Description
Summary
WordPress core applies wptexturize() to post titles, content, excerpts, and comments via built-in filters — converting straight quotes, apostrophes, dashes, and ellipses to their typographically correct equivalents. However, this transformation is not applied to DataForm field labels and descriptions, which means user-facing field text renders with straight apostrophes and other untreated punctuation.
The problem
Field definitions like this:
'description' => __( "Select any items this coupon can't be used for.", 'test-project' ),
Render with a straight apostrophe (') instead of a typographic one ('). WordPress already considers this worth fixing for post content — the same standard should apply to form field text that users see.
Context
This came up while working on typography improvements in a project built on DataForms. The feedback from @tyxla was that this should be solved at the DataForm/core level rather than in individual products, so that all consumers benefit.
The current gap is that wptexturize() is PHP-only and DataForm is a React component, so there's no clear path to apply these transformations today.
Possible approaches
Server-side: Apply wptexturize() to field labels and descriptions in the REST API layer before data reaches DataForm — consistent with how core handles the_title and the_content
Client-side: Create a JavaScript texturize() utility within @wordpress/dataviews that DataForm applies when rendering field text
Hybrid: Texturize on the server for PHP-registered fields, provide a JS utility for client-only fields
I'd love to hear from the maintainers which approach fits best with the DataForm architecture. cc @oandregal
Related
WordPress wptexturize() documentation
Activity
j111q commentedon Apr 7, 2026
@aduth here's the issue :)
tyxla commentedon Apr 7, 2026
@aduth I hear you'd like to tinker with this, so I'll drop it off my list for now. Do let me know if I can help with reviews and stuff though!
My 0.02 euro cents: I'd love to be able to achieve this without having to create a JS port of
wptexturize().oandregal commentedon Apr 7, 2026
For awareness, I'm working moving the DataViews/DataForm config (field definition, view/form config, etc.) to the server.
aduth commentedon Apr 7, 2026
@oandregal Do you see that being something where it'd be reasonable for the server part of DataViews configuration take care of the
wptexturize?To me, this doesn't really feel like a DataViews-specific problem, and more a general problem of "how do we consistently ensure user-facing strings use typographically-correct characters".
My instincts lead toward:
<Texturized>), though this definitely gets into the realm of reimplementing / portingwptexturize. I'd be curious what the concerns you have are, @tyxla . This is something we've done already with e.g.wpautop(@wordpress/autop), although maybe that one does serve as a cautionary tale with its many issues over the years 😄 I'd like to think texturizing is a bit simpler.I think if DataViews already plans to support some level of server registration capability, it makes sense that it could handle texturizing as part of its abstraction layer. Because I don't think it's appropriate to just texturize all strings returned by a REST API endpoint, but may be appropriate for a higher level of abstraction aware of how these strings are used for field labels, descriptions, etc.
tyxla commentedon Apr 8, 2026
Well, texturizing is one of those things that sounds simpler than it actually is. It's not a huge deal, of course. My biggest issue with having a JS port is that we have to maintain all the changes in both places, and it's something that is very easy to go off track.
I do agree with you that, ideally, this is something that should be handled consistently across the board.
oandregal commentedon Apr 9, 2026
The plan is for fields to be defined in the server, so that's something it could take care of. Though, I reckon some fields (those wanting to define any special behaviour via JavaScript) may still be defined client-side. It's going to depend on specifics, but perhaps those cases do still need texturizing in the client (or at build time).