Wikifunctions:Type proposals/Grammatical gender (m/f)

Summary

This enumeration represents the masculine and feminine grammatical gender for languages that have exactly these two genders.

Done: Z25340

Uses

• Why should this exist?

To work with languages that have two grammatical genders, such as French or Spanish.

• What kinds of functions would be created using this?

Mappings to Wikidata items, selecting the right adjective form, getting the grammatical gender of a noun, etc.

• What standard concepts, if any, does this align with?

Grammars of the respective languages.

See List on Wikipedia.

Structure

This type is represented as an enumeration with two values. Like all enumeration types, it consists of a single key. The key is an identity key.

Values

There are two values.

1. Feminine
2. Masculine

Example values

Value

{   "type": "Grammatical gender (m/f)", "value": "Masculine" }

{   "Z1K1": "Znnnnn", "ZnnnnnK1": "Zmmmmm" }

Validator

The validator ensures that:

• the identity key points directly to a value of this enumeration

Identity

Two values are the same if their identity is the same ZID.

Converting to code

Python

We represent them as a String with their ZID.

JavaScript

We represent them as a String with their ZID.

Renderer

As for all enumerations, the renderer displays the label of the value object.

Parsers

As with all enumerations, there is no parser, but a selector based on pre-defined values.

Alternatives

• Instead of an enumeration, this could be a type with a single key that has a Wikidata item reference pointing to the respective item
• In the code conversion, we could represent them as Booleans or a Number. Both requires an arbitrary mapping that may be regarded as problematic.
• In the code conversion, we could use a simple string "m" or "f".
• We could skip this type and just have a single type collecting all grammatical genders.
• We could skip this type and just use Wikidata items directly instead.

Comments

•  Support as proposer. --Denny (talk) 14:19, 7 February 2025 (UTC)
•  Oppose on preference to an item reference. Perhaps an object with the ZID and item reference? Feeglgeef (talk) 14:30, 7 February 2025 (UTC)

  Interesting suggestion! Would need to figure out what that would mean for the UX. I added it as an Alternative. --Denny (talk) 14:40, 7 February 2025 (UTC)

  I don’t see why it would make any difference to the UX. The user would see a dropdown containing the object labels, and selecting from the dropdown selects the persistent object by reference to its ZID. The item reference would be an additional key that should appear as a link to the Wikidata item simply because that is how a Wikidata item reference (Z6091) behaves. (That said, I have previously suggested that Persistent object (Z2) should have an additional key for a Wikidata reference (phab:T344170#9758774), so I should note that I no longer fully support that suggestion and I would consider it inappropriate here, while fetch Persistent object (Z828) remains our only means of accessing such a key (in theory: phab:T366246)). GrounderUK (talk) 16:21, 16 February 2025 (UTC)

•  Support --Ameisenigel (talk) 20:33, 7 February 2025 (UTC)
•  Support. Jérémy-Günther-Heinz Jähnick (talk) 15:48, 8 February 2025 (UTC)
•  Support VIGNERON (talk) 09:49, 9 February 2025 (UTC)
•  Support Votes are supposed to be self-signing replies, but whatever… The conversion to code is unclear, but arbitrary strings like “m” or “f” may reflect a Latin bias and alternatives may not appear to be gender neutral. We could just use QID or ZID strings, but the readability of the code would suffer. In any event, the “masculine” QID happens to be alphabetically later and numerically lower (and shorter) than the “feminine”. When it comes to creating ZIDs, we might choose to create them in the opposite order (and perhaps create “common” and “neuter” before we create either of them).--GrounderUK (talk) 17:50, 16 February 2025 (UTC)

Discussion

Some of the discussion for this type and the related types (m/f/n, c/n and a/i) should probably be had in a single centralized place. I suggest Wikifunctions:Project chat#Natural language functions.