CNLabelContactRelation&NegativeMediumSpace;YoungerCousin&NegativeMediumSpace;MothersSiblingsDaughter&NegativeMediumSpace;OrFathersSistersDaughter | Hacker News Reader

CNLabelContactRelation&NegativeMediumSpace;YoungerCousin&NegativeMediumSpace;MothersSiblingsDaughter&NegativeMediumSpace;OrFathersSistersDaughter

developer.apple.com

211 pointswonderfuly176 comments

Open articleView on HN

At first glance this looked like a code smell, but after some reflection I can't think of a cleaner, more readable way to uniquely identify each possible relationship -- especially in a strongly-typed language with an IDE.

Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...

Amen. Sometimes it takes what it takes to be precise.

You need an intermediate representation (like a tree) rather than attempt to brute force every possible permutation up until some arbitrary point. Even if that weren't the case, it'd be better to give it a more obscure name or create some kind of naming system and then document it rather than demonstrate why self-documenting code can become self-defeating if taken to an extreme.

The issue of a tree is you could trivially create nonsensical relationships. An alternative would be some sort of nested attributes / tag set but even that's not excellent.

A second issue is, this is probably a localisation / cultural concern: below, yorwba notes that this relationship is a specific term in chinese kinship: https://en.wikipedia.org/wiki/Chinese_kinship#Common_extende....

And generate the list using metaprogramming at compile time.

Not sure, but I sort of expected this monstrosity happens because the labels are intended to be localizable.

Why would an obscure name be better? This looks like an example where a very specific relationship is needed, and the name specifies precisely what that is. Choosing an obscure name for this feels like an attempt to hide the fact that this is a special case by using vague terminology.

Trees can't be used for relationships, due to the crazy things that people can do with each other. You'll need a DAG, and you'll need to detect cycles.

https://stackoverflow.com/questions/6163683/cycles-in-family...

Here's the likely explanation for these: https://en.wikipedia.org/wiki/Chinese_kinship#Common_extende...

And video version: The Complicated Chinese Family Tree [https://www.youtube.com/watch?v=nCFRoILS1jY]

And an online calculator to try: http://tool.bm8.com.cn/kinswoman/

`Colleague` in `CNLabelContactRelationColleauge` is spelled incorrectly.

If you have a macOS or iOS beta installed, please report that through the Feedback app on either?

Why on earth would someone do bug fixes for free for a corporation that has cash reserves of $250 billion but is too stingy to pay for quality control?

Because otherwise thousands of developers will have to see that typo for the next ten years.

Like "Referer" :-) https://en.wikipedia.org/wiki/HTTP_referer#Etymology

But by fixing it yourself, aren't you effectively training the corporation to stay sloppy? Sure, this bug is fixed right now. But a year down the road, when the staff count for quality assurance gets renegotiated, the position to deliver quality out of the box gets weakened, resulting in even more bugs of this kind.

This is slightly absurd. It's reporting a very minor bug, not offering to implement a whole feature.

Are you saying that no-one should report anything because it encourages them to let bugs slide into production?

> Are you saying that no-one should report anything because it encourages them to let bugs slide into production?

No, of course not :) That would indeed be absurd. What I meant was this particular case. Apple of all companies is by no means incapable of hiring people to deliver quality. They make billions upon billions by avoiding taxes[0] and shifting production to deleloping countries [1]. If a company like this learns that it can externalize QA even more, they will do so. We are not talking about social contract like situtions here, this isn't open source software.

[0] = https://itep.org/fact-sheet-apple-and-tax-avoidance/

[1] = https://www.theverge.com/2019/6/28/19102703/apple-mac-pro-ch...

Apple's bread-and-butter is products. To the extent that they shift their focus from their products, they jeopardize profits and every other measure of business success.

Good QA is part of being focused on products. So our response (or lack of response) to glitches like this in their software is very unlikely to affect their overall approach. Either they're product-focused or not: if they are, they'll be profitable and QA will be good. If not, they'll eventually fade away anyway.

... All to say, if you want to see issues like this fixed, I suggest reporting them and not worrying about it.

No.

But at the same time you can't really admonish someone for not doing something you won't do either.

I still don’t think this is a good solution because of the common CNLabelContactRelation prefix. It would be better to introduce a CNLabelContactRelation enum? Then the enum cases would be much less painful. Or at least an empty enum as a namespace:

  enum CNLabelContactRelation {
    static let aunt = "…"
    static let auntFathersBrothersWife = "…"
  }

In Objective-C (and C), enum members are unscoped. So in your example "aunt" would be in the global namespace.

A pretty idiomatic (and trivial to implement) Scala way of doing this would be to have a DSL with a name for each relation and compose them together using function application. So to express "MothersSiblingsDaughter" you'd write "mother sibling daughter". The whole expression would return an object which contains a linked list of the individual components, consed together by each individual function application in the chain.

Of course, this is kind of co-opting the call stack to build up at runtime what the compiler can already provide as an AST, so it might be better to just use a macro.

This representation can't be serialized quite as easily as a single symbol or whatever Apple is doing, but it is infinitely flexible. And it seems like a code smell to me that they have a special case for the father's brother, while the mother only has a generic "sibling." It should be up to the view layer to determine that kind of localization-specific logic. If you just store a completely arbitrary relation then you can punt it to the localization to decide how to translate that into meatspeak.

As noted elsewhere, this is more than likely for localization which composing would not enable. Would also explain the asymmetry, does it match Chinese? https://en.m.wikipedia.org/wiki/Chinese_kinship#Common_exten...

Would it not be better to just allow the user to label the relation the way they want and only give options for some most common(important?) ones ?

I can see why this is needed. English has very broad words for relatives like "grandfather" or "aunt". Most languages have more specific words, especially Chinese where there are separate words for fathers or mothers side, older or younger and sibling or siblings spouse. You also often use these relation words rather than their names when referring to a relatives. If this code was in Chinese, they would all be short words.

English words like "aunt" cannot really be translated into Chinese. If you are translating a book you either try to figure out the exact relation from the context, or just pick one if it doesn't matter. In someones address book you can't do that.

Genuinely curious, but is it actually like that in most languages? I wondered if it was maybe an East/West difference, since I haven't come across that in my French & German learning, and I didn't think Dutch or Danish were like that either. But apparently Swedish does have this (eg faster/moster for paternal aunt & maternal aunt)?

(Most of my learning is via Duolingo, so I'm no expert, just curious.)

faster = faders syster = father’s sister. Same for all of them.

Ours is pretty simple, I imagine this system is intended to cover Chinese kinship which is _really_ complex. https://en.m.wikipedia.org/wiki/Chinese_kinship#Common_exten...

Didn't even English have a bunch of words that were lost as time went by?

We do have quite a few words in Lithuanian (e.g. for maternal/paternal branches and more detailed words for "X in law"). But it was getting simplified in the past few decades. I've heard quite a few words that I couldn't describe without looking at the dictionary.

Yup - https://www.umanitoba.ca/faculties/arts/anthropology/tutor/k...

Sweden has it, at least for aunts/uncles, and grandparents (and great grandparents, and great-great-grandparents...).

For aunts its faster/moster (portmanteau of father-sister, mother-sister, roughly). For uncles its farbror/morbror (lit. father-brother, mother-brother).

For grandparents its farfar/morfar (father-father, mother-father) and farmor/mormor (father-mother, mother-mother).

A great grandparent could be e.g. a farfarsfar, or father-fathers-father.

Modern Russian has no difference between paternal/maternal aunt/uncle (though there are apparently archaic forms that denote the difference that no one uses).

On the other hand, it has different words for "wife's mother" and "husband's mother", which in English are both "mother-in-law". Similar for the "father-in-law" relationship: different words for "wife's father" and "husband's father". Similar for sibling-in-law relationships.

(Of course there's the open question of whether Russian would count as "East" or "West".)

Turkish is like that, with mind-bogglingly specific words for apparently half the planet that are your distant relatives.

It’s losing them fast though. Newer generations just don’t really care, so the words are falling out of use. I really only know cousin, aunt, uncle.

Indian languages have this sort of kinship granularity. Some of these distinctions include:

* Maternal/paternal parental siblings, with distinct terms for their respective spouses

* Maternal/paternal parental sibling - distinct terms if they are older or younger than your own parent

It’s a bit anglocentrists to never think that ”oh maybe there are other systems where it makes sense.” Hell, _most_ languages have more words for kinship than English! I always found it odd for example that grandfather doesn’t specify on which side. Like, how is that not super useful information?

You say Maternal/Paternal Grandparents, or add last names, or use different names (eg Granny and Nana). I can't think of a situation where I've had to differentiate them as relatives, only as individuals, so I can't see a distinction being that useful.

Really, you’re going to defend this lack of precision? I’m sure you can get by but having precise words is rarely a loss. Anglocentric superiority complex eh.

You're right that I'm stuck in the Matrix so to speak, so I may well be missing out on something I'm not aware of. But I don't believe I've ever had to use the words 'Maternal/Paternal GrandMother/Father/Parent' which must say something about how often its used.

Maybe we could turn it around, maybe you only use the word because it exists, maybe its like defenestrate. We could get by perfectly well without it.

I don't believe I expressed on opinion on whether any one language was 'better', I could wax lyrical about the warts and shortcomings of the English language, I don't know enough about any other languages to say whether they are better or worse.

Please don't break the site guidelines by adding personal swipes to an argument.

https://news.ycombinator.com/newsguidelines.html

I disagree that calling out anglocentrism is a "personal swipe," it is relevant to the argument (i.e. that it is hard to see beyond your biases.) Discussion should surely not be stymied for the sake of civility, better we step on each other's toes and get our point across than sit in our respective corners and sulk.

I'm sure there was a better way to say what I said, but it was not mean-spirited as I am sure you can see.

Apple. Red apple. Green apple.

Grandfather. Maternal grandfather. Paternal grandfather.

Try making a five year old say ”maternal grandfather,” other languages have two-syllable words for all of these, like the Chinese words for which these are made.

Five year olds get along fine with whatever practices their family uses, for a five year old's life.

Is there a notion in linguistics of languages being more "modular", i.e. tacking on details like this through additional words, versus having more and more specific words to cover these cases?

Coming from my native German, I am very much used to the former, so I always find it interesting to see how different other languages are structured sometimes.

Not quite the same thing, but languages (like German) that build up words for complex concepts by forming big words out of little ones are called agglutinative[1].

[1] https://en.wikipedia.org/wiki/Agglutinative_language

If I recall correctly from my very limited knowledge, German is not really agglutinative, as it mainly just has the ability to combine preexisting nouns together into one word, while agglutinative languages take a root and then add a pre- and suffixes to build up new words related to the meaning of the root.

Taking the 7th example from this table [1], while you could theoretically construct something like "erfolglosenmacherwerden" in German and have it still sound somewhat comprehensible, that is not something that is actively done in the usage of the language and would sound about as strange as coming up with "to unsuccessfulmakerbecome" in English.

[1] https://aimdanismanlik.files.wordpress.com/2012/04/539526_38...

German is not considered an agglutinative language (you can google it if you don't believe me). German has long compound nouns, which isn't really the same thing.

English has long compound nouns too, by the way. You can make basically arbitrarily long nouns like "chief regional dairy inspector" in English. In German you would write this without spaces between the words. That's just a typographical convention, not a linguistic difference. It doesn't mean German's structure is fundamentally different from English's, and isn't what linguists mean by "agglutination".

In Vietnamese there are at least 4 different relationships that we call "uncle" (father's/mother's older/younger brother) in English! I have no idea how you refer to cousins. My teacher told me when he visits family he often doesn't know the word for his own relationships. Apple trying to capture a complete multilingual kinship lexicon sounds like an impossible task, I guess they must be focussing on specific languages here (Chinese is a good bet).

I read a book where this difference in expressiveness removed a subtlety of writing from the translated version.

The original English version had a passage where it was unclear (on purpose) which grandmother was being referred to (it later turned out to be the one you didn't expect). However, with Swedish having no generic word for grandmother (only mormor and farmor), this nuance was lost in the translation.

Similarly, English words "brother" and "sister" are sliced into five words in Korean:

    Elder sister of a girl
    Elder brother of a girl
    Elder sister of a boy
    Elder brother of a boy
    Younger sibling of whatever gender

So every time a "brother" or "sister" appears in English, a translator has to figure out their relative age, or make a wild guess.

There’s also CNLabelContactRelationColleauge. Oops :)

https://developer.apple.com/documentation/contacts/cnlabelco...

Spalling mistek

So out of curiosity I Googled it. Either it's a really common mistake or a regional thing. "Colleauge" has 857k results.

https://www.google.com/search?q=%22colleauge%22

表姐, in case you were wondering.

I'm assuming those Mandarin characters comprise the word for that relationship? I was wondering why this existed and I thought maybe they were adding the Hindi words for specific relatives (there's many, I assume the same is true for Mandarin).

Mandarin is a spoken language. The characters are "Simplified Chinese" in this case. The characters will sound different read in different languages.

e.g. the two Traditional Chinese characters 東京 translate roughly to "Eastern Capital" and are read dōngjīng, while they are also valid Japanese Kanji where they have the same meaning and are read as Tokyo. (Yes, the name of the capital of Japan.) Interestingly, Běijīng and Nánjīng similarly mean "northern" and "southern" capital respectively.

There was once an Eastern Capital in China which is also named as Kaifeng, the capital of the Northen Song Dynasty. It is to east of Chang'an, which is now Xi'an, and the capital of most of earlier dynasties.

In Chinese culture, your male line ancestry matter more. Your mother's family is considered auxiliary ('外家'), thus only your father's brother's children are considered in the same family, and these cousins are labeled “堂”, all the other cousins are labeled "表”, and "姐" means older sister.

Is this why it is a mother's sibling of any gender, but only a father's sister?

That's my understanding, a difference is made between paternal lineages (through the father's brothers) and maternal (either father's sister or any sibling of the mother).

Possibly denoting similar v different family names?

The "CN" is just the prefix for the Contacts framework, it doesn't refer to Chinese

表姐 means older female cousin of a different surname. If surnames are always passed down via the father that implies an elder cousin who is either your mother’s sibling’s daughter or your father’s sister’s daughter.

So what happens if, by chance, a woman in your family marries someone of the same surname? Does the 表姐 label then not apply where it otherwise would?

The phone will freeze until the battery is completely drained. NEVER connect the charger while in this state!

Simple; that was forbidden:

https://books.google.com/books?id=u9MUAAAAIAAJ&pg=PA19#v=one...

Should still be the same. By the way, it's considered quite unlucky/distasteful to marry someone with the same surname.

It's still a specific relationship in chinese kinship, which is likely why it was included as apparently CNf statically encodes all possible relationships.

And, in fact, CN has never referred to Chinese - it's an ISO two letter country code abbreviation for the PRC, admittedly - but the ISO two letter language code would be ZH for the Chinese language.

Exactly... Could it not just have been named

    CNContactLabelRelation表姐
?

Is Chinese the only language with this relationship?

Also, identifiers in Apple frameworks are always ASCII.

They could have used Pinyin. Even people who don’t speak Chinese and have to look it up would have an easier time understanding it than trying to parse this identifier.

When I put this in Google Translate, it auto-detects Japanese and gives me "outer cover." When I specify Chinese, it just says "cousin." So it's not trivial to look up.

Presumably you would google "CNBiaoJie" and find Apple documentation explaining the concept.

(As an aside, Google Translate is a terrible way to look up the definitions of specific words. It is not a Chinese-English dictionary and doesn't try to be. Wiktionary would be a much better free option.)

Google translate and Bing translate are extremely unreliable for ideographic languages.

And then every time you re-read the code you have to look it up to understand 1/ what the hell is even this and 2/ is it the right one at the right place.

Whereas with this English symbol that might not fit on a screen, there are none of those problems?! If the concept is foreign to you to begin with, but you have to care about it for some reason, you're going to have a bad time with either 1 or 2 no matter what the symbol is. (Though I agree that transliterating to BiaoJie would make it easier.)

Yes, which I think is easier than having to parse and understand this identifier every time you see it.

Especially since after a few times you will remember what it means and not have to look it up anymore. There's a good reason we use jargon for complicated concepts rather than re-explaining them every time they're used. "while" is a lot easier to understand once its meaning has been explained to you than "EveryTimeWeGetHereCheckIfThisConditionIsTrueAndExecuteThisCodeBlockAndJumpBackHereIfSo".

I'm not sure it's the only culture having this specific relationship, but it's perhaps better to make sense to some than to none?

A Chinese person, an Apple engineer and a HN reader walk into a bikeshed...

In case you're serious I'd have to rely on IDE completion or copy/paste to input this, not being familiar with chinese input methods. It would also make it trickier to compare identifiers and make sure that it makes sense.

I think it makes more sense to keep all identifiers in English or alternatively provide completely localized versions of the API in other languages, going halfway is just going to confuse everybody. Remember for instance the confusion created by PHP using hebrew in the symbol for the '::' operator: https://stackoverflow.com/questions/592322/php-expects-t-paa...

I am genuinely curious why not. Interesting to know that history about php!

A middle ground might have been to use a transliteration such as CNContactLabelRelationBiaoJie.

Your point about input makes sense in that it's technically possible to type the English identifier without Chinese input methods, although I would be surprised if anybody typed that long-ass English identifier without IDE completion or copy-paste either!

The point about being able to more easily compare, I disagree with - the long identifiers are hard to check.

IMO if an API exposes an uncommonly-known but well-defined concept, I think it's acceptable, and better, to ask users of the API to learn the concept before use rather than paraphrase it.

It better matches what developers are likely going to try to do: if anyone is ever going to write a program that has to care about this case, I'm pretty sure the spec isn't going to be something like "if the contact is the user's elder female cousin who is either the user's mother's sibling's daughter or the user's father's sister's daughter..." - it's likely going to say, if not in Chinese, "if the contact is the user's 'biaojie'..."

There is good precedent for this kind of preference for expressing concepts that aren't broadly familiar in technical APIs. You'll get some symbols containing words like AffineTransform or CMYK in it, and probably many programmers wouldn't know what they stand for either until they need to learn what they are, but that's ok and better than dumbing down the API to something like RotationOrTranslationOrResizingOrCombinationThereOf or PrimarySubtractiveColorSystem.

> In case you're serious I'd have to rely on IDE completion or copy/paste to input this, not being familiar with chinese input methods. It would also make it trickier to compare identifiers and make sure that it makes sense.

I'm not sure it's easier with the super-large English name

Looks like this constant should be parsed as: ElderCousin && (MothersSiblingsDaughter || FathersSistersDaughter)

Mother's Sibling's Daughter or Father's Sister's Daughter.

FYI, Mother's Sibling is 舅舅 (Mother's Brothers) or 姨 (Mother's Sisters), and Father's Sister is 姑姑.

二舅 Mother's second Brother?

Younger Cousin should be 表妹. Was the title edited?

Sadly yes, because "younger" is longer than "older": https://news.ycombinator.com/item?id=20352001

For those in this thread, the mods adjusted the link slightly from Elder to Relation; please keep that in mind when reading.

From Elder to Younger, actually.

“There are only two hard things in Computer Science: cache invalidation and naming things.” [1]

[1] https://martinfowler.com/bliki/TwoHardThings.html

And off by one errors

If only there were 1 based PLs.

The 1st one? (It wasn't the zeroth language, which is probably why it couldn't use 0-based indexing)

Smalltalk arrays and strings are 1-based.

Perl supports this. Optionally, on a per-file basis. Because it’s Perl.

https://perldoc.perl.org/perlvar.html#%24%5b

Lua is a famous one that defaults to 1-indexing for arrays.

They don't fix off-by-one errors, just move them around.

HyperTalk and AppleScript. And I think in old versions of Visual Basic it was common to use 1-based arrays (although you could set the range to anything)

"LET by-ones = by-gones WITH <ol start = 0>"

And CSS...considering that this title broke HN on mobile

For a long time, the Carbon universal headers Included a plain, non-namespaced (c header) MacTypes.h which included:

enum { h = 0, v = 1 };

This could lead to very confusing compiler errors... it was there for compatibility with an anonymous pascalnunion that let you treat a pascal Rect as an anonymous array of two Point structures..

Well, there's CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter, which is two letters longer than CNLabelContactRelationElderCousinMothersSiblingsDaughterOrFathersSistersDaughter.

https://developer.apple.com/documentation/contacts/cnlabelco...

This is my favorite topic.

Well the article draws enough attention to the cause

Ok, we changed to that from https://developer.apple.com/documentation/contacts/cnlabelco.... Thanks!

Does this now hold the record for most frivolous moderator story edit?

Not just that, it actively broke and confuses existing discussions.

I'm grateful that Apple at least prefixed this. IIRC, between iOS 11 and 12, Apple added a Contact class somewhere within their standard set of frameworks. I was maintaining an app that used CoreData as a store and did not have prefixed Core Data entity names. And of course it had its own Contact class.

Long story short, I started building against the newer SDK and the app started crashing in the most oblique way possible. Prefixing the entity and class name solved the problem, but I only stumbled on that through a combination of luck, intuition, and half a day of banging my head against a wall.

Apple recommends to use at least a three character prefix in your objective-c classes to avoid collisions.

I am well-acquainted with Apple's recommendations. The codebase I inherited was not. Unfortunately, Apple's Core Data documentation is also not acquainted with Apple's recommendations: https://developer.apple.com/library/archive/documentation/Co...

Why is everyone assuming this is about Chinese??? CN is the class prefix for the Contacts.framework library, like every other Apple API. For example:

CoreLocation: CL (CLLocation)

SpriteKit: SK (SKScene)

CloudKit: CK (CKRecord)

CoreVideo: CV (CVBuffer)

LocalAuthentication: LA (LAContext)

So on and so forth...

> Why is everyone assuming this is about Chinese???

Because the Chinese kinship system has a specific term for the relationship described by this constant.

It's not about the "CN" bit. People are talking about why the variable exists at all. Essentially the reason being ventured is that that relationship has a specific name and meaning in Chinese with no English equivalent beyond an exacting familial definition. Imagine trying to express "grandfather" in a language that doesn't have the concept. You might end up with "father's father."

(I know nothing about Chinese. Just reporting what's been said elsewhere.)

> Imagine trying to express "grandfather" in a language that doesn't have the concept.

Or, for a more concrete example: "daughter-in-law". Many of the English "-in-law" relations may seem foreign to cultures with different conceptions of the extended family.

I spent 10 minutes laughing about this and the worst part is my wife asking why am I laughing and I cannot explain why

yeah, you cannot

NativLang did a video about kinship systems that is relevant here: https://www.youtube.com/watch?v=YOi2c2d3_Lk

Upvote for breaking HN CSS on mobile.

A good example of poor naming. Explained:

Your younger cousin sister, either from one of your mother's brothers and sisters, or from one of your father's sisters.

Or two characters in Chinese: 表妹(BiaoMei). If she is from one of your father's brothers, she's your 堂妹(TangMei). The latter is regarded as being closer because you share the same family name, but nowadays it just doesn't matter any more.

Some of the other commenters think it's 表姐. No matter who is right, you see, the long name bears no clear meaning even for Chinese.

The other commenters are saying 表姐 because it was originally "Elder", not "Younger". The moderators decided to change it and break all the discussions.

Can HN add wordbreaking css on mobile?

This breaks the width of the page on mobile.

Looks like a good place for some zero-width spaces.

https://en.wikipedia.org/wiki/Zero-width_space

Those aren’t automatic, though.

HN already supports title edits, so it's simpler than changing the CSS, and it's easier to read because the breaking is on the internal word boundaries. Here's the title with the zero-width spaces added:

CN Label Contact Relation Elder Cousin Mothers Siblings Daughter Or Fathers Sisters Daughter

EDIT: HN strips zero-width spaces and replaces them with normal spaces, so I can't post it here.

Then the title would not make sense anymore. Adding a simple css rule would also be futureproof, because i’m quite sure this is not going to be the last time an absurdly long title word appears.

Does this page have some sort of camel-case aware word breaking? As I resize the page I notice it always remains broken at a word boundary and never breaks inside a word.

Ok, I see it now: there are wbr tags between the words on the page. TIL.

Anybody care to introduce me to this? Why does it have to be father's sister but mother's sibling? And how does elder and younger cousins behave differently?

I am pretty sure it is because in some languages (such as Arabic), there are specific, different words for relatives in those different cases. Someone more knowledgable than I can probably confirm.

This one seems to come from chinese

* in many EA and SEA culture, there's a difference made based on the age differential aka different term of address to people older than you v younger than you, also gender

* chinese (and likely others) also make a difference between patrilineal relationships and matrilineal, so there's a term of address for people related through the father's brother (and thus sharing your family name) versus other parent's sibling (not sharing your family name).

The combination of the two yields what you have above:

* cousins through your father's brother (sharing family name) are 堂 (táng) all others are 表 (biǎo)

* older brother is 兄 (xiōng), younger brother is 弟 (dì), elder sister is 姊 (zǐ) and younger sister is 妹 (mèi)

Therefore an older "sister" (same generational rank) through an other line than your father brothers would be 表姊 (biǎozǐ).

Well we mainlanders prefer 姐（jie）. Biaozi sounds the same as bitch so it's never heard.

Java Swing took verbosity even further than that. I present to you a 92-character class name [1].

> InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Thankfully, I think they fixed it in the newer version.

[1]: https://twitter.com/peterlawrey/status/577176384520384512

Needs CNFathersMothersNephewsCousinsFormerRoommate

You missed a sibling or younger or elder in there somewhere.

It's a Spaceballs reference. :)

I see your schwartz is as big as mine!

Is this just one of those exceptional cases when having a strict variable naming convention doesn't work out?

Seems to be working fine.

What else would you name it?

CNBiaoJie

Still easier to understand than this monstrosity, even for those who don’t speak Chinese (assuming they can google the documentation).

I have no idea what "BiaoJie" is (well, in context, I assume it's a romanization of the pronunciation of 表姐), so that name would be completely unhelpful. Whereas the current name describes the relationship such that I can understand it, even if I don't know why this particular relationship is deserving of a name.

Something like CNBiaoJie also assumes that Chinese is the only language that names this relationship, and I don't know if that's true.

I have no idea what ElderCousinMothersSiblingsDaughterOrFathersSistersDaughter is, and understanding and remembering "BiaoJie" would be much easier for me than re-parsing that every time. As I pointed out in another comment, there's a reason we give short names to complicated concepts instead of spelling them out every time. "while" is a lot easier to understand once its meaning has been explained to you than "EveryTimeWeGetHereCheckIfThisConditionIsTrueAndExecuteThisCodeBlockAndJumpBackHereIfSo".

> Something like CNBiaoJie also assumes that Chinese is the only language that names this relationship, and I don't know if that's true.

No it doesn't, not any more than having an identifier called "Sister" assumes that English is the only language with the concept of sisters.

BiaoJie is literally the transliteration of Chinese. So yes, naming it BiaoJie is saying this is explicitly Chinese.

I guess I'm confused as to the specificity of this. Why are a paternal uncle's daughters not included? Why only elder?

Also curious as to why this is important enough to have a specific type of contact for?

It’s kind of nice seeing the homepage with a fixed row height per story! I guess it will not last bit that was a nice thing that came of this. Thanks, OP :)

For those using Refined Hacker News[1] for Firefox on Android, you can add this to the Custom CSS field to prevent the overflow:

    tr.athing td.title:not([valign="top"]) {
        word-break: break-word;
    }

[1]: https://github.com/plibither8/refined-hacker-news

Winforms has some gems:

DataGridViewColumnDividerDoubleClickEventArgs

ListViewVirtualItemsSelectionRangeChangedEventHandler

There is also this classic:

https://github.com/mattl/opensource.apple.com/blob/88cbaab4a...

This is a joke right? Please explain if not. Why wouldn’t you just name the variable relationship (or CNRelationship to adhere to nonsensical globals) and abstract the method for getting there to other logic?

Camel case needs to die, it's been too long and it's not funny anymore.

Could these ever be swiftified as enums?

Well first cousin anyway.

Help, this post is breaking Hacker News mobile because the title is too long without spaces.

wat? :D

That label is so long it’s breaking the HN front page layout for me on mobile.

Same here. I notice it's truncated in the comment dialog, why not also the main page?

HN should add the CSS rule "word-wrap:break-word". In fact this rule should almost always be the default for text that might contain excessively long words (such as user-submitted text on forums).

(...Or german)

Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz

1: https://de.m.wikipedia.org/wiki/Rindfleischetikettierungs%C3... - check out the voice version!

You've got to love the "abbreviations" for these laws.

RflEttÜAÜG

I like that better than the American way of inventing stupid names, so that the acronym is "cute".

You should use  or <wbr> between wordparts for 100% pedantically correct word breaking.

Yup. @dang, can you fix this?

In principle yes, but I tried in 4 (edit: 5) browsers and couldn't reproduce the problem, and it's late here and I'm running out of steam. So you may have to suffer overnight. Sorry about that.

Edit: ok, thanks to https://en.wikipedia.org/wiki/Unicode_character_property#Whi... I put in a bunch of &NegativeMediumSpace;. I hope that fixes it because I need to sign off now. If it isn't fixed, it would be helpful if someone would email hn@ycombinator.com so we see that in the morning. Short term memory does not survive the firehose.

Thanks, it’s not a huge issue! I’m able to see the issue with safari on my iPhone, FYI.

Happened for me on iOS 13 if it helps. Font stays the normal size but you have to scroll right. If you zoom out, it’s a bit harder to read but not bad.

Firefox and Firefox Focus on Android present the same issue.

It's reproducible for me when viewing the home page in Chrome 75 on Android 9 (Pixel 2 XL).

It probably shouldn't be visible in title tag: https://i.imgur.com/a1RLCt0.png

You're right.

I was wondering what was going on!

That's why it's broken! Was so confused

So that explains it!

I've attempted to fix it. Details at https://news.ycombinator.com/item?id=20352144.

Thanks. That fixed it for me (chrome on Android)

Also broke hckrnews.com on mobile.

I was wondering what was going on there.

¯\_(ツ)_/¯

Reply on news.ycombinator.com