Genealogy has a blind obsession with birth names. When a person was NEVER known by their birth name, this obsessive behavior reduces Genealogy to being about ‘trivia’ rather than the actual life of the people is describes.
It makes family sheets effectively hide the daughters & wives who may have spent 88% of their life answering to their married surname.
I’d like to see an option that intelligently displays end-of-life names as the Preferred name.
For some people, there will only be a birth name used throughout their life. But for women (some with multiple marriages), this would typically be their final “Married Name” rather than “Birth Name”. For some, it would be a nickname and might include a title or suffix. (Like “Dr. Bud Smith, Sr.”)
But since this IS a genealogical tool that must bow occasionally to its obsession, I’d like to be able to globally swap between Birth name & End-of-Life name as the ‘preferred’.
In a similar vein, why isn’t there a née (or couverture) name format display option for women in reports? So a couverture format might inserted as “Mrs. Samuel (née Mary Jones) Smith”
As the genealogist and Gramps user already have this ability. You can add as many alternate/other names as needed for any person in the database. And you as the user can slot which of these names to slot as the person’s preferred name.
Granted you are proposing to have Gramps do this automatically. I for one do not like automated data entry (surname guessing being the exception),
Maybe this functionality could be an addon.
You can put the 'nee Jones' in the Married Name entry.
Given name = Mary
Surname = Smith
Surname connector (or second surname prefix) = née
second Surname = Jones
Which surname gets the Primary tag ??
Given name = Mary
Surname = Smith
Surname connector (
second Surname prefix = née
second Surname = Jones
Surname connector )
Things would look better if the added space for the connectors was not there.
I think it is “Preferred” in People names and a “Primary” only in Place names.
I’d like to only set preferred as an override. Similar to the Grouping override.
And I’d much, much rather have an implicit functionality rather than an explicit (and error prone) manual abuse of the Prefix. Especially since that approach would conflict with any couverture surname that already had a prefix.
And I agree on the space suppression option for connectors. I have a lot of people that have a prefix but who adopted a form where the space is omitted. (And my own surname, with the “Mc” prefix, is the most common example of that happening in many surnames.)
When you have more than one Surname entered, you can make any of the other surnames Primary. In the case I posit, you can make the Jones surname Primary and that name will group with the Jones names and not with the married names Smith.
But, again, a manual override. This isn’t something where I need an immediate workaround. (We could probably write a reusable SuperTool script that looks for Females with a married name and chooses the last Alternative name that is of Married name type as the Preferred name. And a similar script that looks for Alternative names with explicit date ranges covering the death date.)
And the term “Primary” probably should not be used in this discussion. It is in GEPS 21 and a bunch of other areas. But the GUI uses Preferred (and unfortunately, default in the context menu) as the section header. The “primary” also carries contextual baggage from the Primary/Secondary object relationship in the database. And there’s ordering controls in the list of Alternative names that add yet another layer of nuance.
All males and unmarried female are known by their birth name their whole life. Yes married females are known by their married name, but in childhood they are known by their birth name. In many documents you still find the birth name mentioned for married females. Using the birth name isn’t a far-fetched obsession.
That’s possible manually by making the last “Name after marriage” as prefered name, but hard to implement automatically as a tool or for displaying.
Many “juniors” were never known by their given name, they went by their middle name or a diminutive from the moment of birth. The birth name was just for legal use. Like a 3rd (III) will often only called “Trip” from the very beginning. Likewise, a Margaret, Annis, or Harriet might’ve been Peggy/Daisy, Nancy or Hattie everywhere but the legal paperwork. So, after marrying, neither their given nor surname will resemble the birth name.
An all-too-common special case is that an infant adoptee might never even KNOW their birth name.
Yes, but naming and the useage of names have a lot of variation regionally and culturally, so it is impossible to choose a name which works everywhere. Usings birth names makes sense because you often find it in sources and documents, even if this name wasn’t used in everyday life.
That’s what I mean by being “arguable”. The point could go either way and be still be “correct”.
That’s an approach that is more respectful of the wife’s heritage.
And the cultures where a child inherits a compound matronymic patronymic surname is also more respectful.
Of course, the cultural norm for what is considered ‘respectful’ changes too. My childhood included the militant portion of the women’s liberation movement in the US. When I was born, it was considered disrespectful to include a married woman’s given name in a newspaper article unless she was widowed. And her age was a taboo too.
Since I’m generally using this as a research collection tool but expect that it will be used to generate genealogical reports, I hoping for a flexibility in the display name. One that fully leverages the dynamic support provided by a database.
Like the complex subject being discussed for Places (where the names and enclosing civil division change historically), a person’s names change over their lifetime. And it would be nice if the software allowed switching the display name globally instead of individually.
So the Display might have a global switch between: birth name, preferred name, death name & juncture name. (Juncture name might be the name at a specific point in time. So the name in a parent’s obituary would be whatever the current married name was at that point.)
I very much dislike the idea of “last married name” being the default for females. One common scenario is a long (and hopefully happy) married life, then a much shorter (hopefully happy) marriage in retirement, if her husband pre-deceases.
I am much happier with the default genealogy notion that the name someone is born with is fixed, and that later names are modifications to the original.
To circumvent the difficulty of finding the subject of records that (of course…) use a female’s married name, I long ago created my own search interface, that uses the surnames of all spouses-of-an-individual as well as all surnames of the individual.
Yes, the Last Married Name would horrible as a default. I only want that during research phases when transcribing obituaries or biographies.
So an assignable global set to “Birth name” for (with a “Preferred” individual override) would be the optimal solution. But I expect that it would an evolutionary pain-in-the-butt, just as dates & Places have been.
My current workaround is to create a “compound married name” for women having multiple marriages. It uses the multiple surnames that are listed in date order. I set this as her preferred name.
Any chance of sharing your custom search interface? Maybe as an alternative Filter Gramplet for the People category view? That option to spouse search would make finding a “Mrs. Sam Hill” a lot easier.
As others have pointed out, there are too many regional differences regarding names. If there were some optional default actions regarding names, I for one would not find any use for them.
Half of my ancestors lived in the Netherlands. One cool aspect of Dutch genealogy is that in the official church and civil records, women are always referred to by their birth names, even if they are otherwise socially known by their husband’s surname. That makes the research so much easier, and I never bother recording a “married” name.
I like the idea of adding a date range to a preferred or alternate name. (In a few cases, I can identify a specific date when a particular name change occurred.) But given the complexities of naming, I don’t think I would find any use in a global switch for choosing which particular name to display.
In fact this obsession with married names seems to be a peculiarity of the English speaking world, Most of the world people keep their birth names all their life, in some cases it is difficult and expensive to change a name, in Nederland it needs an act of parliament and royal assent.
With gramps I am quite happy to add alternative name and nicknames but all my records are stored by birth name and I do not want any automated system changing it.
I was looking at the Data Model and it was unclear how the lists of primary_name and alternate_name are referenced. (BTW, the interface uses “Preferred” & the data model has “primary” at 2 different places: the 2nd is inside the primary_name.)
I was hoping the Primary/Preferred would just be a flag… like it seems to be for the surname_list.
If it was just flag, I could have a couple custom Attributes with different configurations defining which of the alternate_name was primary. I could just have a SuperTool script that sets the flag. With a tweak that small, I could almost justify overriding the “last modified” as being only a display change, not a significant data change. (Just like adding something so temporary as Tags changing the modify date is crazy. I wish tags had a list of objects rather than objects having lists of tags. They’d be so much faster.)
But if Gramps actually re-writes & re-orders the whole alternate_name list each time, that’d be too risky.
Writing lists with strings means dealing with ordering, the potential for delimiters inside the strings, Unicode oddities. And determining if the alternate names are referenced by an array index or handles. And determining if the primary_name is ALSO in that alternate_name array or if it has to be concatenated into that array and the new primary_name has to be copied out and then removed from the alternate_name list.
But if it is just a unique ‘true’ flag then redesignating is dead simple.