From: Doug B. <dou...@gm...> - 2009-09-09 00:09:00
|
Gramps devs, There has been a conversation going on about adding some additional name fields here: http://www.gramps-project.org/bugs/view.php?id=3161 The proposal is actually two, independent suggestions, and they can be discussed separately, but I mention them both here as they could be added together, if that is the consensus. The first proposal is to add a secondary_surname field which could be treated as either: 1) a middle name 2) additional surname(s) 3) a secondary surname The idea is that Gramps (and GEDCOM) doesn't give enough flexibility for organizing surnames. Gramps (and GEDCOM) just have the single field, and people have requested additional fields to organize a name's surnames. This can be added (with a database change), a new keyword/code could be added for the display_name functions, the UI could support another picklist for editing it, and eventually we can add search and additional GUI/output support. It looks like we would lose this field in a GEDCOM export, as the name would become just part of surname. An alternative possibility is to add a delimiter (perhaps a comma?) to the current surname field, and break it into multiple surnames in the UI. However, a second field would be easier, and would be all that the proposal would call for. For example, a third surname field would not be necessary in the future. The second proposal is to re-add the nick_name field. Nick_name was part of the name fields at one point but was removed (as far as I can tell) because the reasoning was that it was actually a nickname of the person (not the name) and thus rightfully belongs as an attribute of a person rather than as another field of name. However, this decision effectively removed nickname from being able to be used with the other name fields. For example, it is not possible to show a person attribute in the name displayed in the Person View. The name display engine works quite well as it is, and would require some major adjustments to get a nickname person attribute into it (if one even wanted to do that, which would be a major hack). However, re-adding a nick_name field would be easy, and would satisfy what many of us inappropriately use the call_name field for. There are some further details in the issue tracker. We're looking for further feedback on whether adding one, or both of these fields is the right thing to do. Thanks for any comments! -Doug |