I haven't been a dev in a bit, but I'd say between having a longer variable name, and having to crack open the fucking dictionary.... I have a clear preference.

Exactly: one option is a single-time, fixed cost (single-time-ever if you write it as:

  CN_LCR_BiaoMei = 77,
  // either mother's sibling's daughter or father's sister's daughter
  // aka female cousin involving at least one female parent

), while the other adds a constant tax on all uses of the variable (well, constant in this case) in perpetuity.

You can apply this logic to anything. If you were working on database software, would you make a variable transactionId or idOfGroupOfStatementsThatMustBeExecutedAtomically ?

I was thinking along these lines when I wrote my post... I think there's some domain knowledge that can be expected. A DB dev is probably expected to know what an "id" is. But probably 99.9999999% of devs even working with the address book APIs can't be expected what to know what "BiaoMei" is unless they are Chinese to begin with.

If you're working in a domain when you need to care about Chinese kinship relationships then it's just as reasonable to expect you to know what "biao mei" means as it is to expect a DB engineer to know about transactions.

You have to worry about discoverability the other way: how would I (dumb american) know that's something I should be worried about?