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).
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 ​. 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.
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.
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.
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?
表姐 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.
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.
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.)
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".
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
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:
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.
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.
Well, there's CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter, which is two letters longer than CNLabelContactRelationElderCousinMothersSiblingsDaughterOrFathersSistersDaughter.
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.
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.
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.
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.
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?
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.
> 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.
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.
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 = "…"
}
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.
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..
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)
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.
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 :)
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.
* 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ǐ).
187 comments
[ 0.26 ms ] story [ 260 ms ] thread1: https://de.m.wikipedia.org/wiki/Rindfleischetikettierungs%C3... - check out the voice version!
RflEttÜAÜG
Edit: ok, thanks to https://en.wikipedia.org/wiki/Unicode_character_property#Whi... I put in a bunch of ​. 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.
I was wondering what was going on there.
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.
Possibly denoting similar v different family names?
https://books.google.com/books?id=u9MUAAAAIAAJ&pg=PA19#v=one...
Also, identifiers in Apple frameworks are always ASCII.
(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.)
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".
A Chinese person, an Apple engineer and a HN reader walk into a bikeshed...
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...
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.
I'm not sure it's easier with the super-large English name
FYI, Mother's Sibling is 舅舅 (Mother's Brothers) or 姨 (Mother's Sisters), and Father's Sister is 姑姑.
This breaks the width of the page on mobile.
https://en.wikipedia.org/wiki/Zero-width_space
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.
Still easier to understand than this monstrosity, even for those who don’t speak Chinese (assuming they can google the documentation).
Something like CNBiaoJie also assumes that Chinese is the only language that names this relationship, and I don't know if that's true.
> 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.
https://developer.apple.com/documentation/contacts/cnlabelco...
This is my favorite topic.
Ok, I see it now: there are wbr tags between the words on the page. TIL.
> InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Thankfully, I think they fixed it in the newer version.
[1]: https://twitter.com/peterlawrey/status/577176384520384512
Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...
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....
https://stackoverflow.com/questions/6163683/cycles-in-family...
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...
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.
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.
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..
[1] https://martinfowler.com/bliki/TwoHardThings.html
https://perldoc.perl.org/perlvar.html#%24%5b
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.
https://developer.apple.com/documentation/contacts/cnlabelco...
https://www.google.com/search?q=%22colleauge%22
DataGridViewColumnDividerDoubleClickEventArgs
ListViewVirtualItemsSelectionRangeChangedEventHandler
https://github.com/mattl/opensource.apple.com/blob/88cbaab4a...
Also curious as to why this is important enough to have a specific type of contact for?
* 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ǐ).