I did see a few threads on this but nothing directly applicable.
I have a few Van Pettens in my family now. I never used the surname prefix feature but apparently PGV generated it for some of them. These are Americans and I decided that no one will be looking for them as Petten so I removed the prefixes and corrected each one to just Van Petten in the surname field.
The slight remaining problem is that when I display married names, two women who married Van Pettens only show up under P, not V, despite the GEDCOM not having the prefix separated. Women who are Van Pettens by birth show up under V.
The "Edit name" box breaks out the prefix in the born surname but not the married surname, and it seems that PGV's search handles these differently as well. How can I get all of the Van Pettens to show up under V? I didn't see any config option for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the current method of treating surname prefixes as being completely separate from the rest of the surname is wrong.
I'd expect the "van", "von", etc. to be an inseparable part of the surname, so that the "van Ormer", "Vanormer", "von Kalkreuth" etc. individuals would be in the "V" list. That's how these names appear in the phone book, and that's what people would expect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not Dutch so I can't say what is really right or wrong.
I bet if I had a whole lot of Van Pettens in my family I wouldn't think this solution was so perfect. It does seem inconsistent, and potentially misleading or even erroneous, that PGV filters those two cases differently. So maybe perfect isn't a great term, but Greg's suggestion did exactly what I wanted with these two INDIs.
I guess it would be nice to be able to turn off the prefix filtering. Or better yet, simply show the Van Pettens under both V and P, so the Dutch and the Americans can find them easily.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<I'm not Dutch so I can't say what is really right or wrong>>
There is no right or wrong. I'm sure I'm not the only one with *both* European and North Americans in my tree, so the default behaviour will always be wrong somewhere!
One solution might be to let PGV keep the assumption that "Van" is a prefix, but make it an option to index names under "SPFX SURN" instead of "SURN". This should be pretty easy to implement.
Another solution could be to extend the GUI, so it can create the name-parts for level two names (e.g. married, hebrew, aka, etc.).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wouldn't it have to do both? If you set the option to allow SPFX indexing, you'd still have people showing up under each interpretation as long as the GEDCOM isn't doctored per your suggestion.
I think the second part of your solution is more important. If the GEDCOM is consistent, and PGV treats the different (given and married) surnames consistently, then at least family members will all show up in the same place.
Also, it seems that PGV makes that assumption in at least two places. Once when it filters the names, and once when it took my Van Petten and broke it up into Van and Petten when I created a new relative somewhere. Maybe that part should be rethought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<it took my Van Petten and broke it up into Van and Petten when I created a new relative somewhere>>
This is in the GUI/editor. It copies the surname from the husband, but not the level 3 parts. If these were copied across, then the rest of the logic should work just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<One solution might be to let PGV keep the assumption that "Van" is a prefix, but make it an option to index names under "SPFX SURN" instead of "SURN". This should be pretty easy to implement.>>
That sounds good to me. I have a bunch of "Le Surname" indis. They are all from Jersey and England. I'm not 100% sure on Jersey but in all English directories and lists they are indexed as if the name was "Lesurname". That makes it desirable that they be listed under L and not under the first letter of the second part. Especially when a lot of the North American connections have contracted some of the names to Lesurname instead of having the 2 separate parts.
It's not a huge deal but it is kind of a pain to have to remove the "Le" from the prefix box and put it into the surname box every time I add a child. If there was a toggle for the sorting it would make it a lot easier than fiddling with the prefix all the time :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Somebody has already made the suggestion that I would consider to be optimal:
Since we're really only trying to build individual and family lists that can be used to navigate to the desired individual or family, PGV should index these lists using both forms of the name:
Once in the Dutch manner, where "van Gogh" is listed under the "G", and then a second time in the American/English/German/French, etc. manner where "van Gogh" is listed under "V".
When creating the database indexes from which the Individual and Family lists are ultimately derived, PGV should ignore the presence of spaces and dashes so that "van Gogh" would sort together with "Vangogh". However, the lists have to preserve the original appearance of the surname in question. The user should not be aware that internally PGV treats "van Gogh" as if it were written "VANGOGH".
The current implementation in PGV demands that all users be aware of which letter strings at the beginning of surnames are prefixes and should be ignored when looking for a particular surname in lists. This might be second nature to Dutch people, but it certainly isn't for much of the rest of the world.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We keep separate copies of the "display" name and the "sort" name. We never show the "sort" name on screen. This should be a simple case of changing the way we calculate the "sort" name.
PGV already allows you to have more than one sort name. For example, a Spaniard (with two surnames), such as José Luis Rodríguez Zapatero is currently listed under *both* Rodríguez and Zapatero
So, I'll add a config option to allow the user to choose whether Van Gogh is listed under
"V"
"G"
Both "V" and "G".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The default for this option should be "both". I question the need for such an option, since users who expect to find "van Gogh" under "G" would be successful, as would those who expect to find that name under "V".
We can't predict which choice a given user might make.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Since we're really only trying to build individual and family lists that can be used to navigate to the desired individual or family, PGV should index these lists using both forms of the name: "
The only other solution I can see would be a custom tag for how to sort.
1 NAME Vincent /van Gogh/
2 _SORT Vincent van /Gogh/
would sort into the 'G' but still be displayed as
van Gogh, Vincent
(I'm not recommending this, just saying it would be possible)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<The default for this option should be "both". I question the need for such an option, since users who expect to find "van Gogh" under "G" would be successful, as would those who expect to find that name under "V".
We can't predict which choice a given user might make. >>
Default of both would be okay with me. Just being able to find the person in the expected place would be the desired result.
The only slight caveat would be a possibility of confusion for a user actually looking for Gogh (no prefix) and then getting to a page that has Van Gogh. Not sure if that would happen often enough to worry about it though.
On the other hand, if it isn't that much extra work, why not have a config option? Just have the default at both and if someone is unhappy they can change it. Everyone is then happy :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did see a few threads on this but nothing directly applicable.
I have a few Van Pettens in my family now. I never used the surname prefix feature but apparently PGV generated it for some of them. These are Americans and I decided that no one will be looking for them as Petten so I removed the prefixes and corrected each one to just Van Petten in the surname field.
The slight remaining problem is that when I display married names, two women who married Van Pettens only show up under P, not V, despite the GEDCOM not having the prefix separated. Women who are Van Pettens by birth show up under V.
The "Edit name" box breaks out the prefix in the born surname but not the married surname, and it seems that PGV's search handles these differently as well. How can I get all of the Van Pettens to show up under V? I didn't see any config option for this.
<<so I removed the prefixes and corrected each one to just Van Petten in the surname field>>
You can do the same with MARNM fields, but you need to do it with raw-gedcom editing. There are two equivalent options
1 NAME Mary /Doe/
2 GIVN Mary
2 SURN Doe
2 _MARNM Mary /Van Petten/
3 GIVN Mary
3 SURN Van Petten
1 NAME Mary /Doe/
2 GIVN Mary
2 SURN Doe
1 NAME Mary /Van Petter/
2 TYPE _MARNM
2 GIVN Mary
2 SURN Van Petten
I'd suggest the first one.
I agree.
I think the current method of treating surname prefixes as being completely separate from the rest of the surname is wrong.
I'd expect the "van", "von", etc. to be an inseparable part of the surname, so that the "van Ormer", "Vanormer", "von Kalkreuth" etc. individuals would be in the "V" list. That's how these names appear in the phone book, and that's what people would expect.
Perfect, thanks.
So we are basically overriding the assumptions that PGV is making about the surname prefix by forcing the prefix into the married surname?
<<So we are basically overriding the assumptions that PGV is making about the surname prefix by forcing the prefix into the married surname?>>
Yes. If you specify the "component" parts explicitly, they are used.
Otherwise PGV has to "guess" the name structure. It has a list of common prefixes.
<<That's how these names appear in the phone book>>
Doesn't that depend on where in the world you live? For example, in the Netherlands, van Gogh would be listed under G. See
http://en.wikipedia.org/wiki/Dutch_name#Surnames
I'm not Dutch so I can't say what is really right or wrong.
I bet if I had a whole lot of Van Pettens in my family I wouldn't think this solution was so perfect. It does seem inconsistent, and potentially misleading or even erroneous, that PGV filters those two cases differently. So maybe perfect isn't a great term, but Greg's suggestion did exactly what I wanted with these two INDIs.
I guess it would be nice to be able to turn off the prefix filtering. Or better yet, simply show the Van Pettens under both V and P, so the Dutch and the Americans can find them easily.
<<I'm not Dutch so I can't say what is really right or wrong>>
There is no right or wrong. I'm sure I'm not the only one with *both* European and North Americans in my tree, so the default behaviour will always be wrong somewhere!
One solution might be to let PGV keep the assumption that "Van" is a prefix, but make it an option to index names under "SPFX SURN" instead of "SURN". This should be pretty easy to implement.
Another solution could be to extend the GUI, so it can create the name-parts for level two names (e.g. married, hebrew, aka, etc.).
Wouldn't it have to do both? If you set the option to allow SPFX indexing, you'd still have people showing up under each interpretation as long as the GEDCOM isn't doctored per your suggestion.
I think the second part of your solution is more important. If the GEDCOM is consistent, and PGV treats the different (given and married) surnames consistently, then at least family members will all show up in the same place.
Also, it seems that PGV makes that assumption in at least two places. Once when it filters the names, and once when it took my Van Petten and broke it up into Van and Petten when I created a new relative somewhere. Maybe that part should be rethought.
<<it took my Van Petten and broke it up into Van and Petten when I created a new relative somewhere>>
This is in the GUI/editor. It copies the surname from the husband, but not the level 3 parts. If these were copied across, then the rest of the logic should work just fine.
<<One solution might be to let PGV keep the assumption that "Van" is a prefix, but make it an option to index names under "SPFX SURN" instead of "SURN". This should be pretty easy to implement.>>
That sounds good to me. I have a bunch of "Le Surname" indis. They are all from Jersey and England. I'm not 100% sure on Jersey but in all English directories and lists they are indexed as if the name was "Lesurname". That makes it desirable that they be listed under L and not under the first letter of the second part. Especially when a lot of the North American connections have contracted some of the names to Lesurname instead of having the 2 separate parts.
It's not a huge deal but it is kind of a pain to have to remove the "Le" from the prefix box and put it into the surname box every time I add a child. If there was a toggle for the sorting it would make it a lot easier than fiddling with the prefix all the time :)
Somebody has already made the suggestion that I would consider to be optimal:
Since we're really only trying to build individual and family lists that can be used to navigate to the desired individual or family, PGV should index these lists using both forms of the name:
Once in the Dutch manner, where "van Gogh" is listed under the "G", and then a second time in the American/English/German/French, etc. manner where "van Gogh" is listed under "V".
When creating the database indexes from which the Individual and Family lists are ultimately derived, PGV should ignore the presence of spaces and dashes so that "van Gogh" would sort together with "Vangogh". However, the lists have to preserve the original appearance of the surname in question. The user should not be aware that internally PGV treats "van Gogh" as if it were written "VANGOGH".
The current implementation in PGV demands that all users be aware of which letter strings at the beginning of surnames are prefixes and should be ignored when looking for a particular surname in lists. This might be second nature to Dutch people, but it certainly isn't for much of the rest of the world.
We keep separate copies of the "display" name and the "sort" name. We never show the "sort" name on screen. This should be a simple case of changing the way we calculate the "sort" name.
PGV already allows you to have more than one sort name. For example, a Spaniard (with two surnames), such as José Luis Rodríguez Zapatero is currently listed under *both* Rodríguez and Zapatero
So, I'll add a config option to allow the user to choose whether Van Gogh is listed under
"V"
"G"
Both "V" and "G".
The default for this option should be "both". I question the need for such an option, since users who expect to find "van Gogh" under "G" would be successful, as would those who expect to find that name under "V".
We can't predict which choice a given user might make.
"Since we're really only trying to build individual and family lists that can be used to navigate to the desired individual or family, PGV should index these lists using both forms of the name: "
The only other solution I can see would be a custom tag for how to sort.
1 NAME Vincent /van Gogh/
2 _SORT Vincent van /Gogh/
would sort into the 'G' but still be displayed as
van Gogh, Vincent
(I'm not recommending this, just saying it would be possible)
<<The default for this option should be "both". I question the need for such an option, since users who expect to find "van Gogh" under "G" would be successful, as would those who expect to find that name under "V".
We can't predict which choice a given user might make. >>
Default of both would be okay with me. Just being able to find the person in the expected place would be the desired result.
The only slight caveat would be a possibility of confusion for a user actually looking for Gogh (no prefix) and then getting to a page that has Van Gogh. Not sure if that would happen often enough to worry about it though.
On the other hand, if it isn't that much extra work, why not have a config option? Just have the default at both and if someone is unhappy they can change it. Everyone is then happy :-)