Pronoun attribute for artists

Tags: #<Tag:0x00007fd2d872ab20> #<Tag:0x00007fd2d872aa58> #<Tag:0x00007fd2d872a990> #<Tag:0x00007fd2d872a800>

as i mentioned, the list can be exhaustively extensive — and that’s only considering English!
my proposal for now would be to implement only 9 or, depending on how it’s implemented, 5 generic options:

  • neutral
  • mixed — for groups only
  • female
  • male
  • “any” — when an artist doesn’t mind, or accepts all pronouns

if there is a consensus to further specify pronouns, we could implement them under these categories.

i don’t disagree with a free‐text field approach, with locale options (how we do for aliases), but maybe it could be on top of the 9/5 options i’m proposing, similar to how it works for instrument performance relationships — you select “instrument” and then you can set the specific instrument(s).

i think it matters as much as we might care about personal relationships between artists, like romantic involvement, which we do store on MB. and for some artists, this part of their identity is relevant to the work they make. it’s not urgent to store this data, but i think it would be valuable to do so.

that makes perfect sense, so however pronouns are implemented (string or table), they’ll need to be

as for free text (string) vs.

we could also work with/fork an existing pronoun db, if we use, the pronouns field could be a url

if we go the “work with/fork” route, instead of supporting multiple pronoun locales/languages in MB, we could work to make (or a fork) support more languages, and use multiple URLs on the artist

having it be a URL could also help with the


1 Like

Seems on a similar level to the gender field imo, it’s all personal information to the artist.

But both could certainly be considered unnecessary I suppose. I feel the gender fields main use is to disambiguate artists atm?


That was @paulakreuzer original post. Different conversation to this thread. Database needs gender as it is relevant to the artist. And the artist needs to be able to define their gender as they see fit. That Ticket needs fixing first before the pronoun one.

That is database relationships again. Already it is “siblings” and not “brother\sister”, “parent” not “mother\father”. That is for how people are connected to each other. It is interesting to see if someone has musical parents.

A personal pronoun is important to the person, but not relevant to the music they create. Why does MB need pronouns? If the database attempted to make phrases that included a pronoun, then yes. but I don’t see anywhere this happens. All it is going to lead to is another mass debate where people get confused and heated. It will lead to errors in data being selected when new artists are added to the database. It is data that will be very hard to research for the majority of Artists already in this database. It will lead to people guessing. What would David Bowie use if still alive?


There is some value in pronouns as it helps us talk about an artist - ‘she composed x’ or ‘they composed x’

But similarly to gender and location fields I guess they are not strictly necessary?


MB never has relationships like that. It is always “artist name composed x”.

I think the idea is that it helps us as people talk about the artist, not that it helps the database show stuff differently :slight_smile:


This is a database of music facts. We don’t talk about music here. It is not that type of forum. If MB kept biographies, then I’d understand the need for expanding to that type of data. But biographies are elsewhere accessed via a link. This seems to just open the database up to too many errors and arguments.


Given this would be an optional attribute (like “Key” for works) that would only show in the form if the user asks for it (or if it is already filled), and there would almost certainly be a rule to only add it if there’s a direct source from the artist (their website, twitter account or something or the artists themselves adding it), I cannot see where the errors and arguments would come from. If you don’t care about these you can just ignore them, and if you care it should be easy to see whether the source given agrees with the data entered.


I also just want to point out that this can be said about literally any new field added to the database (and has been for a lot of them!). It usually turns out to be a non-issue 99% of the time.


Thing is, what’s the criteria for a detail being a “music fact”? Doesn’t the artist’s life and how it informs their work fall under that criteria?

Songs by cis men are often informed by their experiences as a cis man, and similar applies to songs by cis women. “9 to 5” isn’t just a song about the daily grind, for example, it’s about misogyny in the workplace, for example. Works by trans artists are often informed by their experiences as a trans person. Works by black artists and artists of colour are nearly always informed by their experiences.

None of these works are born in a vacuum.

Granted, it’s probably all irrelevant when you just want to tag your FLACs correctly, but it might serve to inform the everyday user about that music’s origins. :slightly_smiling_face:

(Goodness knows, some people in the world really need that education.) :grimacing:


I agree that the gender issues raised a few years ago by @paulakreuzer need fixing. I don’t know if it got lost in a ticket or somewhere else. I agree with you @TrollDecker that it is very relevant to the music created by some artists. Even more part of their identity than their nationality. All goes towards the experience that creates the music. I was just not sure if we needed the pronouns as well as it is data that is going to be harder to locate and verify.


these discussions revolving trans people are not about you, the childish comments you add in every thread are obnoxious and unfunny. act like an adult or mind your business.


if we do this, we might need it to always be a vote because trolling could be common.


This post was flagged by the community and is temporarily hidden.

my point is it can be valuable data. as you point out, is it relevant to the music who an artist is related to? maybe it is, maybe it isn’t. it’s biographical info, as you say. why would pronouns be less relevant, especially for artists that do care about them?

as @TrollDecker said, different parts of a person’s identity and experience can inform their work. just like we have a gender option (which needs to be improved!) that could also be argued is not ultimately relevant (but it is to many artists — and i think it does, in a world that still lacks equity), knowing someone’s pronouns could indicate things about their background to better understand their work.
i would also like to point out that MB data also exists outside MB. there are many organizations that use it for their own projects that could benefit from details like this.

pronouns will most likely be added to artists that do find it relevant, because they stated it somewhere. cis or binary artists most likely use the common pronouns for their gender identity, so we wouldn’t need to add pronouns to them (unless explicitly stated).


If editors turn out to use the field to troll, then those editors should be reported and get blocked. If it turns out to be an overwhelming problem, then sure… But let’s start from the assumption that most editors are here in good faith and that we’ll deal with the ones that are not. :slight_smile:


It’s strange that on one hand some people seem to find this feature important but on the other hand not important enough to add this information now in the form of annotations.

Their purpose is to add information that usually doesn’t fit into the strict structural data schema of MusicBrainz (be it due to technical limitations that may be addressed later, or because the information in itself has to be free-text).

Why wait and not make do with what you have?


Agreed that until we are able to add these as an attribute, it makes sense to add them to annotations :slight_smile: Please use an easily searchable way, such as “Pronouns: X”, so that they can be easily moved over if this gets implemented.


will this work?