Pronoun fields are an ungainly sop and I’ve been working for four years to at least try and change process and technology to be useful instead.



• As a social signal that needs to be voluntarily seeked, they’re worth little.

• Computers cannot read them anyway. Computers talking to or about a person do not understand the content of pronoun fields.

• Pronouns are an anglocentric approach that does not localize — people in other languages want the way they are referred to to match, and sometimes this means matching grammatical gender and number, not just pronoun. Sometimes it means to do more.

The approach I’ve shipped last Monday is four years of discarded designs and iteration. It lets a localizer write a template string, and then insert user preferences into the process.

You, as a localizer or developer, can write:

"Do you want to call ^[them](…) back?”

and indicate in the … that it needs to be customized, and optionally for who. And then have the OS inject user preferences into the process.

The user preferences type isn’t a modeling of gender (gods know that there’s no good reason to model a person’s actual gender in a system), but also isn’t just a modeling of pronouns or grammatical gender. It’s a bag of declarative grammatical (morphological) properties.

It’s the Morphology type:

Remember that Apple SDK types can expand over time — none of the axes it represents are `@frozen`; they’re merely the closure of properties from all supported languages.

I think this approach is a million times better than the pronoun field alternative. The user deserves to control their experience; a computer can now refer to them correctly, and model that experience for other people; and the user can select the way they want to be referred to with a set of properties for which the UI can make good inferences for cross-language preferences (you can select .feminine gramamtical gender and an English neopronoun, and if it’s not English it’ll fall back.)

Is this perfect? No. It requires a full lexicon and knowledge of the specific language to work the way it’s advertised. And there are some easy concessions in the design for ease of first implementation (e.g., one pronoun). But know I do have design sketches for _all_ language bits that I’d love to support as this thing matures (including, say, using no pronouns, or supporting complex case agreement setups, or split agreement between two parts of a sentence).

But it certainly beats the empty promise of a fucking pronoun field.

ADDENDUM: the worth bit re: pronoun fields above doesn’t mean they’re worthless, it just means that limiting it to just be that signal has exhausted their usefulness.

Add a pronoun field if it’s all you can do.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!