Nedjo Rogers

Already covered in #46, closing.

@danbri > We have tried explicitly to be flexible, respectful and inclusive. The two properties that reference gender are https://schema.org/gender and https://schema.org/suggestedGender for people-audience, and they both lean heavily towards...

> At a minimum, to avoid resonating with and potentially reinforcing a regressive status quo, `GenderType` would presumably need to be expanded to include options that don't align cognitively with...

The [Component Schema](https://www.drupal.org/project/component_schema) project is an option here; see #296. It's based on core's configuration schema API, itself modeled on [Kwalify](http://www.kuwata-lab.com/kwalify). I've just updated #296 with further details on how...

> Or perhaps even more, to distinguish different types of strings: Yes. So far, the custom schema types are mainly focused on the task of processing values to reduce the...

> it might be a good idea to only declare ui patterns that actually need to be ui patterns, and leave the rest as pure components, so not to pollute...

> Converting the schema programmatically into form elements is non-trivial. These couple of Drupal core issues (both long since stalled out) are related: * [Enhance config schema for richer default...

> I imagine something different: Instead of producing a form for an arbitrary pattern, we would filter patterns that match a given schema requirement. Wow, I like this idea. The...

Basic integration of Component Schema and UI Patterns is largely complete, see [[meta] Integrate with UI Patterns module](https://www.drupal.org/project/component_schema/issues/3175327). While that doesn't in itself accomplish everything discussed in this issue, it...

A PR is ready for review at https://github.com/theNewDynamic/gohugo-theme-ananke/pull/540.