Book translators / authors must have a field day with this.

Let's say that a character in book 1 suspects his cousin of committing a murder, and nothing else is revealed about that cousin (let's say it's a side plot) until book 5, where new evidence turns up and he is suddenly found guilty. If you differentiate between male and female cousin, how do you translate book 1 if book 5 hasn't been written yet?

Even better, let's assume the books are finished, the author is dead, but you're translating to a language that differentiates between younger/older cousins / cousins on different sides of the family. You just pick whichever word you like more. Ten years later, Hollywood makes a movie adaptation, and the "male cousin" from your translation is played by none other than Angelina Jollie. Your readers are very confused.

Translation is hard.

Ok so this is for i18n and in English would just be “cousin”? Can we assume there actually is a language somewhere that makes this particular distinction and has a word for it?

They are different concepts.

If you speak Chinese, there is a specific word for this relationship.

Relationship labels should capture the actual labels people routinely use.

Apple does not offer this label to English-speakers, unless you have Chinese as one of your additional languages.

Similarly, if English is not one of your languages, the label for “cousin” will not appear, which is localized in an even more convoluted way in Chinese.

Yes.

Kinda!

If you have a contact with that specific option set, it'd display as

>younger cousin (mother's sibling's daughter or father's sister's daughter).

Not if Chinese is one of your chosen languages, it won't.

EDIT: I see, there were two questions asked, saagarjha answered “yes”, but you’re answering the first question “is this just cousin”.

You are correct that it’s not just cousin, sorry for the correction!

That’s surprising. I’d expect it to be “cousin” in English. Why would it be the more specific string? Is it just too difficult to do the i18n?

While you have a point, imagine the string appearing in a combo box or other list of relationship kinds. It would be very confusing to have multiple options that are all just "cousin".

To solve both that use case and the ones you have in mind, the API could perhaps be extended with a language-aware "normalization" procedure that maps relationship labels in a way that loses information but produces a more canonical label for that language. And you'd use that API only in those cases where it makes sense.

But then that would lead to a contact being displayed slightly differently in different settings, which may in itself be confusing to users.

At some point you just have to give up and call it good enough.

That’s not the use case I imagine. When setting relationships in a Chinese localization this option appears with the correct characters in the dropdown. If that contact is shared with an English locale the attribute is still set but it displays as “cousin”.

People can use iPhones in English and be native speakers of languages that make the distinction; why would you hide that information from them?

Interesting perspective. I define the rules based on the localization but maybe it should be by user. Not really sure how that UX works though.