Subject: Re: [Jmap] [calsify] JSContact: gender property

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 03 Jan 2022 16:35:55 +0100

On Thu, Dec 23, 2021, at 9:08 PM, Darcy Iris wrote:
> My personal recommendation here is not to use a grammaticalGender field as you've described, instead having only a pronouns field, that allows specifying the "full set" (subject pronoun, object pronoun, possessive determiner, possessive pronoun, reflexive pronoun). Not only does this mean it's relatively language-agnostic, it also means that any implementation can refer to the contact using their actual pronouns. 

grammaticalGender needs to stay. A couple of people asked us about the missing GENDER property from VCARD because they stored the grammatical gender in there, especially for salutations in human languages where a grammatical gender is required. We want to provide them with a straight-forward migration path to JSContact and while doing so stop confusing biological sex with grammatical gender.
For salutations, a pronouns property did not seem particularly useful to me: the pronouns are instructive when talking with or about a contact. But for grammatical gender, one would have to know the language the pronouns are defined in, then infer the grammatical gender from the pronoun.

That being said, I do see the additional need for pronouns and it seems services and application developers do, too. Notably, the Google People API has the addressMe field in the Person.gender property. It is a free-text field and the examples suggest to store the pronouns in the form "they/them".
We could certainly add something similar, but is a free-text form good enough? If a structured property is required, then it should allow for more than just the English language. Unfortunately pronouns soon then get complicated.

Cheers,
Robert

---

From: Joris Baum <[email-masked]>
Date: Mon, 3 Jan 2022 16:46:29 +0100

Hi Robert and happy new year everyone :) ,

I also like the proposal and would also vote for keeping it simple and 
not introduce things like variable substitution. For our use case it is 
not necessary to add a biological sex component to JSCalendar. Having 
grammaticalGender definitely improves mapping from vCard to JSCalendar.

As the topic of gender is apparently quite complex and also dynamic, 
maybe it would be a good idea to point to the Vendor-Specific Property 
Extension definition in the gender property section again? This way we 
could encourage developers to come up with their own extensions.

Regards,

Joris

On 23.12.21 20:55, Neil Jenkins wrote:
> Thanks Robert, I think this is a good, well-reasoned proposal.
>
> On Fri, 24 Dec 2021, at 12:48 AM, Ken Murchison wrote:
>> I also wonder if we might want to add a property for a user's 
>> preferred pronouns.
>
> Is that not covered by grammaticalGender?
>
> On Fri, 24 Dec 2021, at 1:51 AM, Andreas Hauser wrote:
>> Not only is there grammaticalGender but also salutations often differ 
>> based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber 
>> Robert“ / „Sehr geehrter Herr Stepanek“.
>
> That feels out-of-scope to me, especially if you have to start 
> introducing variable substitution.
>
> —Neil
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 03 Jan 2022 17:20:33 +0100

Hi Andreas,

On Thu, Dec 23, 2021, at 3:51 PM, Andreas Hauser wrote:
> Not only is there grammaticalGender but also salutations often differ based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber Robert“ / „Sehr geehrter Herr Stepanek“.

Agreed (I am a German native speaker, too).

> To make this most useful in practice, a field for salutation might be considered, taking variables for first name (e.g. %FN), nick name and last name (e.g.%LN): „Dear %FN“, „Dear Professor %LN“ etc.

I agree with Neil that the JSContact spec does not seem the right place for this. Such templates should rather go in the applications and services that build on the contacts data. Note that some of the template language that you suggest is covered by the Unicode Person Name Formatting spec: https://www.unicode.org/review/pri434/ We made sure that the naming properties in JSContact use the same terminology to interoperate with that PRI434.

What we might consider instead is to allow setting modifiers on the grammatical gender:

grammaticalGender:
  - gender:  ("animate", "female", ...") (mandatory)
  - modifiers (optional): list of
      - value
      - type ("formality", "deixis", "number")
   
where

"formality": allows values "intimate", "familiar", "distanced"
"deixis": allows values "proximal", "medial", "distal"
"number": allows "singular" and "plural"

This should cover a good number of human languages. However, I am not a linguist and I am afraid none on this mailing is either?

Cheers,
Robert

---

From: "Robert Stepanek" <[email-masked]>
Date: Wed, 12 Jan 2022 09:16:06 +0100

Sorry for the double cross-post, but earlier in this thread the jmap mailing list got split off.

On Wed, Jan 12, 2022, at 9:13 AM, Robert Stepanek wrote:
> 
> On Fri, Jan 7, 2022, at 9:10 AM, Robert Stepanek wrote:
>> The next RFC draft will reflect these decisions. Thanks to all of you for your input.
> 
> And this is what we will get published in the next draft version soon:
> 
> 2.2.6.  speakToAs
> 
>    Type: SpeakToAs (optional).
> 
>    Provides information how to address, speak to or refer to the entity
>    that is represented by this card.  A SpeakToAs object has the
>    following properties, of which at least one property other than @type
>    MUST be set:
> 
>    *  @type: String (mandatory).  Specifies the type of this object.
>       This MUST be SpeakToAs.
> 
>    *  grammaticalGender: String (optional).  Defines which grammatical
>       gender to use in salutations and other grammatical constructs.
>       Allowed values are:
> 
>       -  animate
>       -  female
>       -  inanimate
>       -  male
>       -  neuter
> 
>       Note that the grammatical gender does not allow to infer the
>       gender identities or biological sex of the contact.
> 
>    *  pronouns: String (optional).  Defines the gender pronouns that the
>       contact chooses to use for themselves.  Any value or form is
>       allowed.  Examples in English include she/her and they/them/
>       theirs.
> 
>    The property values SHOULD be localized in the language defined in
>    the language property.  They MAY be overridden in the localizations
>    property (Section 2.5.1).
>