Quote:
Originally Posted by Manichean
@chaley: Database aspects aside, how would the method you're proposing differ from the behaviour we'd get when using comma as default? If I understand it correctly, it would just replicate that behaviour and thus would probably not be worth doing.
|
No, it doesn't replicate current behavior.
We currently have no real idea how a name is separated into its components. All we know (and this is what I think kiwidude was saying) is how to convert a series of words into another series of words. I was attempting to describe was a way to apply meaning (semantics) to the words. Having this meaning, calibre could correctly display names in either order, and could maintain sort values regardless of order.
For example, consider the name Lim Chun, a person in Malaysia that I know. His name is written in the correct order, but in fact Lim is his family name and Chun is his personal name. Now consider me, Charles Haley, which is written in the correct order but my family name is Haley. What I described could handle both of these cases. The first one would have a flag indicating it was to be displayed LN FN. My name would have a flag indicating it was to be displayed FN LN. Now add Werner von Braun to the mix. The LN is "von Braun" and the FN is "Werner", and if displayed in LN FN format should be "von Braun, Werner". However, in this case the sort string is "Braun, Werner von", where in my case it is "Haley, Charles", and in Lim Chun's case it is "Lim, Chun".
The 'comma' algorithm does not deal correctly with all these cases.