Closed NurMarvin closed 3 years ago
The pronouns object values is not really meant for internal use only and shouldn't be exposed. It also is a representation people may not agree with ("she/they" vs "she/her or they/them" for example).
I also want to add internationalization at some point, hence why I used fixed ids instead of throwing the formatted pronouns down the pipe. Sure I could throw the internationalized pronouns but I don't want to deal with it in this way. Plus it'd mean the pronouns object values become virtually immutable because external apps rely on it, yet generating more troubles.
If your only use for this is to prevent breakage, you should just ensure your code does not blow up if it encounters an unknown pronoun identifier. I doubt any pronouns will be added anytime soon and I'll most likely not remove any. I see this more as some over engineering on your side than on a lack of features on my end.
This PR adds a
/pronouns
route to the public API that allows developers to get an up-to-date map of pronoun abbreviations with their corresponding set of pronouns. This is achieved by just sending thePronouns
object as the response body. This is especially useful to prevent software that depends on the pronoundb.org API from breaking in the future just because a new pronoun was added, which wasn't yet added to the software's own hard coded map of pronoun abbreviations.