webtrees
webtrees copied to clipboard
fisharebest
Comma separated SURN's in individual-lists: the list shows the same surname multiple times
I've multiple surnames as a comma separated list in SURN (see below):
1 NAME Velislava Velcheva /Marinova/
2 TYPE MAIDEN
2 GIVN Velislava Velcheva
2 SURN Marinova, Marinov, Marinovi
But 'lists -> Individuals' (\individual-list?surname=MARINOVA) shows me only 3x the same surname 'Marinova'.
Shouldn't two of the entries be displayed with the other surnames (Marinov and Marinovi)? Like:
Velislava Velcheva Marinova
Velislava Velcheva Marinov
Velislava Velcheva Marinovi
If this is not possible, then the name should be displayed at least only once.
Since I enter the name also in Cyrillic (again with three SURN's) and the same name is displayed again several times, the table is then very confusing. It makes no sense to show the same name multiple times.
Shouldn't two of the entries be displayed with the other surnames (Marinov and Marinovi)? Like:
No.
The NAME field is used to create the "display" name.
The GIVN and SURN fields are only used for sorting and searching.
2 SURN Marinova, Marinov, Marinovi
This is not how this field was designed to be used.
It was designed to store the uninflected/base version, or the standard spelling.
i.e. you just store "Marinov" here.
According 5.5.1 it's possible to store different family names in SURN. So I think this is valid. But it's ok when webtrees used it in another way.
The GIVN and SURN fields are only used for sorting and searching.
That's why I used it, in special for searching (with all the existing family names). Another example are names from the former called 'Sudetenland'. This was an German/Czech-speaking area and I've a lot of names in a very different spelling: i.e. Schmoranzer, Smoranz, Schmorantz, Smoranc, Schmorantzerin, Šmoranc, Šmorancová. Same persons in different official documents (mixed from german and czech).
> Shouldn't two of the entries be displayed with the other surnames (Marinov and Marinovi)? Like: No.
I would even prefer the name to be displayed only once with the field NAME. Is that possible?
To summarize, I believe that for each entry in the SURN tag a line is output in the “name list”. The value output is based on the NAME tag.
As indicated by Greg, the SURN tag should be used to “normalize” surname spelling variations, and gender based surnames.
I also use this when an individual does not have a surname but their location or patronymic name can be used as a surname after Norway required inheritable surnames by law in 1923/24!
The only time I would use a comma separated list is when the individual had multiple surnames. Or in a rare instance when you had to index the same person under multiple surnames simulating a “clan” or “kin” relationship!
To summarize, I believe that for each entry in the SURN tag a line is output in the “name list”. The value output is based on the NAME tag.
I have the same impression. But it's senseless to print the same name multiple times. Maybe the code can be changed to print it only one time?!
As indicated by Greg, the SURN tag should be used to “normalize” surname spelling variations, and gender based surnames.
This is one (of the undocumented) ways of using it. However, I would also like to have a way to list all known and officially used surnames including the inflected forms. I did this for a while with additional NAME tags. However, the name is then again not correct for gender-dependent forms. Besides the extra work for the creation, the list of names also becomes confusing with increasing number of names.
The use of the comma separated SURN is therefore for me a simple and elegant solution. I can search for the individual names and they are displayed to me compactly in a line togehter with the INDI NAME.
It just bothered me that duplicate names with the same name appear in 'lists-Indi'. If Greg says he won't change this (because he doesn't want comma-separated lists in SURN), then that's ok. I'm just asking if it's changeable.
But it's senseless to print the same name multiple times.
In your example, the surnames are very similar.
But they can be very different. Suppose your surnames are inflected at the beginning, not the end.
1 NAME Mary /Amarinov/
2 SURN Amarinov, Marinov, Imarinov
Suppose we show a list of all individuals with the given name Mary.
Now, we will include the individual three times - once sorted under 'A', once sorted under 'I' and once sorted under 'M'.
Remember, this is a list of names - not of individuals. If an individual has many names, we show them many times.
I think I can't follow.
With your example I see [edit: ~~now~~ again] in all lists only the name 'Mary Amarinov' (partly multiple times). Is this intentional? Do you want to say: "Don't use a separated comma list in SURN because webtrees is not made for this."?
But ...
-
Please note: the image with the red rectangle from the first post is created from the 'lists-INDI' 2nd submenu (the name 'MARINOVA'). It's not the 1st submenu (the letter 'M'). In 2nd submenu the name NAME is written mulitple times and also the URL-link to the INDI is identically. I still think, these duplicates in 2nd submenu makes no sense and the name should shown only one time.
-
When you use only the base/root form in SURN in your example,
1 NAME Mary /Amarinov/
2 SURN Marinov
then you will never find the name 'Amarinov' below 'A' in 'indi-list' (1st submenu). It's only sorted in 'M' -> 'MARINOV'. And you have noticed by yourself: "But they can be very different". So, I think either you have to use the same name in SURN and NAME (without the base form option) or you use a list in SURN.
The system was designed for two cases:
- Individuals with 2 surnames (e.g. Spanish/Portuguese). For example:
1 NAME Jose Manuel /Chunga/ /Castillo/
2 SURN Chunga,Castillo
The individual will be shown in the list of "C" surnames twice. Once sorted under "Chunga" and once sorted under "Castillo".
- Individuals with an inflected surname. For exampe:
1 NAME Maria /Kowalska/
2 SURN Kowalski
This individual will be displayed as "Kowalska", but sorted as "Kowalski"
Lael Kowalski Maria Kowalska Nadim Kowalski
When you add 3 spelling variations, you are creating 3 entries in the table. Because your spelling variations are very similar, they will sort together.
The system was designed for two cases:
1. Individuals with 2 surnames (e.g. Spanish/Portuguese). For example:1 NAME Jose Manuel /Chunga/ /Castillo/ 2 SURN Chunga,Castillo
And again we will see duplicates in 'indi-list' 2nd submenu (= /individual-list?surname not alpha)
I understand why there are two names, but it doesn't make sense to display them twice, since the name and the URL link are absolutely identical. To stress out: I'm talking about the same table cell not for different listings of the same name in the whole table.
Is the change very laborious or is there something else against displaying NAME only once in a cell? It would increase the clarity of the table in your case and also with a number of surnames greater than 2.
displaying NAME only once in a cell?
To point out: only duplicates that are based on the multiple names listed in SURN shall be removed. Other names, created by additional NAME tags of an INDI, should not be removed, of course.
For me it makes sense to show all names in one cell because it shows that the individual was known by multiple names. Proposals:
- remove the link from the second, third, ... name
- show the second, third, ... name in smaller and/or differently colored and/or italic letters.
- implement a button on top of the list "Display/Hide additional names".
or any combination of the above.
For me it makes sense to show all names in one cell
Do you use a comma separated list in SURN or do you use sepearte NAME tags for one INDI? That's different cases and I'm talking only about the first case.
I started with a comma separated list of surnames where I deemed it necessary and moved to separate name tags later. After looking closer at your issue I did a few tests on the webtrees demo server for the current release with a new individual Adam XXX with the additional surname YYY. As you can see from the attached screenshot this Adam is always shown twice in a single cell as Adam XXX Adam XXX, even in the list under YYY. In both lists no Adam YYY is shown.
I agree that the current webtrees solution for this use case is not the best one and I recommend to move to separate name tags and refrain from the commas.
I know where the comma comes from, but I'd say the GEDCOM 5.5.1 specification hasn't done any good by saying
- Different given names are separated by a comma.
- Different name prefix parts are separated by a comma.
- Different name suffix parts are separated by a comma.
- Different surnames are separated by a comma.
- Different surname articles are separated by a comma.
In both lists no Adam YYY is shown.
For me that's ok. For example: YYY is the root name which you usually don't want to see. Therefore, it should not be displayed. But it's important that you can find XXX also when you search for YYY. This is possible here.
and I recommend to move to separate name tags and refrain from the commas.
But then you lost the possibility to search for names (see Point 2. in post https://github.com/fisharebest/webtrees/issues/4455#issuecomment-1145638826)
However, these are all points that go beyond my actual concern. My question is about these duplicates in a cell (see Post 1 and https://github.com/fisharebest/webtrees/issues/4455#issuecomment-1145772138) and whether it is possible (and desired) to remove them.
"lost the possibility to search for names"
I don't understand. Try something like
1 NAME Adam /XXX/ 2 TYPE birth 1 NAME Adam /YYY/ 2 TYPE aka 1 NAME Adam /ZZZ/ 2 TYPE aka
or whatever TYPE you deem appropriate.
"lost the possibility to search for names"
I don't understand.
Greg said that the software was designed for two cases. One of his examples was (without commas):
1 NAME Maria /Kowalska/
2 SURN Kowalski
The 'real' name is Kowalska, but you will not find this name via searching (because the search looks only for 'Kowalski'). With additional names in SURN you will find it.
Try something like
In the past I've used NAME for this (it's somewhere above written) but then the INDI page shows all variants of the name as if they were proper INDI names. Which, however, is not the case (i.e. like the inflected forms Kowalska/Kowalski).
SURN with a comma separated list makes exactly what I want ... except that webtrees shows duplicates in the cell.
the INDI page shows all variants of the name as if they were proper INDI names.
1 NAME Adam /XXX/
2 TYPE birth
2 _AKA Adam /YYY/
2 _AKA Adam /ZZZ/
without any 2 GIVN or 2 SURN tags will hide the alias names on the INDI page. To see these alias names you have to open the NAME box. This creates 3 display names and will show Adam under the XXX, YYY and ZZZ lists with all his 3 surnames in one cell, but you may not like this either.
I understand your GEDCOM solution provides only 1 display name to webtrees for multiple surnames so that this display name is used multiple times in a single cell while 2 _AKA and 1 NAME ... 2 TYPE AKA create additional display names for the same cell.
With GEDCOM 7 the 2 GIVN and 2 SURN tags become less important, even optional, so maybe you should get rid of them.
Other than that I can confirm that the current solution is somewhat ugly and that duplicate display names should be removed.
I've looked again at the code. There are two parts to it, and I was thinking about the other part.
There is logic to examine the 1 NAME records for an individual, and display them all. For example, this name
1 NAME Mary /White/
2 _MARNM Mary /Black/
will create these entries and we will show all of them in the same cell in the table.
| Display | Type | Sort |
|---|---|---|
| Mary White | NAME | WHITE,MARY |
| Mary Black | _MARNM | BLACK,MARY |
If we have this
1 NAME Mary /White/
2 _MARNM Mary /White/
then we will create these entries
| Display | Type | Sort |
|---|---|---|
| Mary White | NAME | WHITE,MARY |
| Mary White | _MARNM | WHITE,MARY |
This will show "Mary White" twice - but the second one will have a tool-tip of "Married name" This is correct - she had two names (with different name types), so we show them all.
In your case, we have
1 NAME Velislava Velcheva /Marinova/
2 SURN Marinova, Marinov, Marinovi
will create
| Display | Type | Sort |
|---|---|---|
| Velislava Velcheva Marinova | NAME | MARINOV,VELISLACA VELCHEVA |
| Velislava Velcheva Marinova | NAME | MARINOVA,VELISLACA VELCHEVA |
| Velislava Velcheva Marinova | NAME | MARINOVI,VELISLACA VELCHEVA |
So now we are showing all 3 names
We could attempt to de-duplicate it here, but that would hide issues where there genuinely are duplicates.
1 NAME John /White/
1 NAME John /White/
Experimenting with the way 2.1.4 works I entered the following 3 individuals: 0 INDI 1 NAME Lael /Kowalski/ 2 GIVN Lael 2 SURN Kowal
0 INDI 1 NAME Maria /Kowalska/ 2 GIVN Maria 2 SURN Kowal
0 INDI 1 NAME Nadim /Kowalski/ 2 GIVN Nadim 2 SURN Kowal
When I go to the Individual List for "K" I see:
When I select one of the highlighted names I see:
I think this works as I would like, and allows you to see each name once and independently.
The 2 SURN Kowal could be anything! I tried:
2 SURN Kowal 2 SURN Kowal... 2 SURN Kowal* 2 SURN Kowalsk*
@Norwegian-Sardines Experimenting with the way 2.1.4 works I think this works as I would like, and allows you to see each name once and independently.
Do you address my statement https://github.com/fisharebest/webtrees/issues/4455#issuecomment-1146203165 related to the single SURN?
@ungeahnt ~~The 'real' name is Kowalska, but you will not find this name via searching (because the search looks only for 'Kowalski').~~
1 NAME Maria /Kowalska/ 2 SURN Kowalski
I'm actually wrong with my assertion that you can't find 'Kowalska' via the search function. I have tested this before, but apparently I made a mistake. I tried it again today and I find all 'Kowalsk*', too. Sorry, no idea what I did differently.
@reteP-riS
without any 2 GIVN or 2 SURN tags will hide the alias names on the INDI page. To see these alias names you have to open the NAME box.
If an INDI page is opened in my installation, then the box is always unopened (regardless of the occurrence of SURN/GIVN). But I will have a closer look on it the next days.
@fisharebest
We could attempt to de-duplicate it here, but that would hide issues where there genuinely are duplicates.
1 NAME John /White/ 1 NAME John /White/
Isn't something like this more likely to be found via 'GEDCOM check for errors'?
@ungeahnt Did you understand what my pictures are showing you?
They show you that you don’t need a SURN comma separated list to group together the various spellings of the same surname! Each surname will be listed once, with the number of individuals having that name, and a total of all individuals with the indexed (SURN tag) value.
As you found the “search” facility finds all variations of the same name.
so my conclusion is that for your instance:
- Enter the name the individual goes by in the NAME tag.
- Enter one (and only one) indexed value in the SURN tag.
The indexed value should be the name stem (in my case Kowal) but it also can be any other value that makes sense.
In you case either pick one of the following as the indexed value (Marinova, Marinov, Marinovi) or find a stem value like Marinov*, but one pick one. Then use that value as the SURN tag for all Marinova, Marinov, Marinovi named individuals.
If you have not tried this then give it a try, because that is what was designed to work in webtrees!
Sorry for the late answer, but I'm a bit busy.
@Norwegian-Sardines
@ungeahnt Did you understand what my pictures are showing you?
Yes, but it's not that what I wanted to achieve with the 'comma separated list'. At the moment I give a try to FONE and ROMN. However, these solutions needs more effort than just adding a single name to a comma separated list. With FONE/ROMN I have to add a complete name with all name parts every time :(. But I think that will be the right way.
But back to the original question:
From the discussion so far, I understand that there should be no use of 'extended' comma separated lists of names. However, duplications occur even under 'normal' wt-conditions (see https://github.com/fisharebest/webtrees/issues/4455#issuecomment-1145772138) and Greg suggested an de-duplication:
We could attempt to de-duplicate it here, but that would hide issues where there genuinely are duplicates.
1 NAME John /White/ 1 NAME John /White/
Do appropriate 'genuine' duplicates cause problems?
- if not, then I would advocate for de-duplication in lists/tables.
- if yes, then it should be included in the GEDCOM error check.