Quantcast

Proposals for additional name fields

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposals for additional name fields

DS Blank
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


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Benny Malengier
2009/9/9 Doug Blank <[hidden email]>:

> 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!

I don't like the comma idea.

If this is realized, then it should be accompanied with a plugin
'Clean Names'. This would allow to have multiple surnames split into
middle name and surname. It would also make the conversion from
present values to new values easier. The plugin should follow the
concept of first viewing the changes that would happen, with actual
change only after clicking accept or continue.

Nickname could also be seen as 'another name', as it is not really
part of the name. But I understand the rationale of having it.
If I remember correctly, somewhere in the past, the label Callname was
changed to the label Nickname because anglosaxon names had no use for
it, but then as it became clear the translations where wrongly
translating the field to nickname, instead of callname (and users of
those locales asking how to store the callname), the english label was
reverted back to indicate 'Callname'.
So it's not that nickname was removed, it was that making it official
that the same field could be used for two different things lead to
problems.

To conclude, for me it is good to add both these fields as official
fields to the name editor and person editor.
In the person editor, I would suggest to add a new line for these
fields at the top, so that the organization is:

Family:                      Suffix/Prefix
Given:                        Call Name:
Middle:                       Patronymic/Title:
Type:                         Nick Name:

Rationale for this: Call name is a part of the given name that is the
call name, so should be on the same line as Given.
Middle name is for many people empty, so should be on the third line
instead of between Family and Given.

If people think Middle name should be with Patromic/Title on line 2,
because that is the more logical thing, then let it be known.

Benny

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Reinhard Müller
Am Mittwoch, den 09.09.2009, 09:39 +0200 schrieb Benny Malengier:
> Family:                      Suffix/Prefix
> Given:                        Call Name:
> Middle:                       Patronymic/Title:
> Type:                         Nick Name:

I think that a middle name is a special case of a given name.

My daughter is Simone Vanessa Müller, she is called "Simone", "Vanessa"
is her middle name.

My gramdmother was Maria Alma Stephanie Höfler, she was called "Alma",
but you wouldn't call "Maria" her "middle name".

What I do now is to list all names in the correct order in "Given" and
to mention the call name in "Call Name", and I actually consider this
sufficient.

I have also added an option to some of my reports to replace the given
name with the call name, so I can print a report with "Simone Müller"
and "Alma Höfler", which is how these people are called usually.

Thanks,
Reinhard

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Peter Landgren
In reply to this post by Benny Malengier
Den Wednesday 09 September 2009 09.39.40 skrev Benny Malengier:

> 2009/9/9 Doug Blank <[hidden email]>:
> > 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!
>
> I don't like the comma idea.
>
> If this is realized, then it should be accompanied with a plugin
> 'Clean Names'. This would allow to have multiple surnames split into
> middle name and surname. It would also make the conversion from
> present values to new values easier. The plugin should follow the
> concept of first viewing the changes that would happen, with actual
> change only after clicking accept or continue.
>
> Nickname could also be seen as 'another name', as it is not really
> part of the name. But I understand the rationale of having it.
> If I remember correctly, somewhere in the past, the label Callname was
> changed to the label Nickname because anglosaxon names had no use for
> it, but then as it became clear the translations where wrongly
> translating the field to nickname, instead of callname (and users of
> those locales asking how to store the callname), the english label was
> reverted back to indicate 'Callname'.
> So it's not that nickname was removed, it was that making it official
> that the same field could be used for two different things lead to
> problems.
>
> To conclude, for me it is good to add both these fields as official
> fields to the name editor and person editor.
> In the person editor, I would suggest to add a new line for these
> fields at the top, so that the organization is:
>
> Family:                      Suffix/Prefix
> Given:                        Call Name:
> Middle:                       Patronymic/Title:
> Type:                         Nick Name:
>
> Rationale for this: Call name is a part of the given name that is the
> call name, so should be on the same line as Given.
> Middle name is for many people empty, so should be on the third line
> instead of between Family and Given.
>
> If people think Middle name should be with Patromic/Title on line 2,
> because that is the more logical thing, then let it be known.
>
> Benny
>
Sounds fine with me, as long as we keep the 'Call Name', which is important for Swedish users.

I have another database field question:
In the Repository View the is a column called 'County', but there is no way to get information into
that column. At least I can't. Is there e field for the county in the database? If not we should
delete the column or if there is a field we should add it to the address editor.

/Peter


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Benny Malengier
In reply to this post by Reinhard Müller
2009/9/9 Reinhard Müller <[hidden email]>:

> Am Mittwoch, den 09.09.2009, 09:39 +0200 schrieb Benny Malengier:
>> Family:                      Suffix/Prefix
>> Given:                        Call Name:
>> Middle:                       Patronymic/Title:
>> Type:                         Nick Name:
>
> I think that a middle name is a special case of a given name.
>
> My daughter is Simone Vanessa Müller, she is called "Simone", "Vanessa"
> is her middle name.
>
> My gramdmother was Maria Alma Stephanie Höfler, she was called "Alma",
> but you wouldn't call "Maria" her "middle name".
>
> What I do now is to list all names in the correct order in "Given" and
> to mention the call name in "Call Name", and I actually consider this
> sufficient.

The above is how callname must be used, and is the correct working order.
You are misunderstanding the meaning of middle. It is the middle
surname, not a part of the given names. See the bug thread. So this is
for spanish/portugueze with multiple family names, of which one is the
main one.
Just as callname, it problably is best to give the field a label that
is more indicative than just Middle.
So let's propose:

Secondary:

and the tooltip on the input field reads: "Secondary Surnames, for
example "João Juan Soares de Sousa" has as Given name: João Juan, and
has two surnames, the principal one being de Sousa, and the secondary
surname (also called sometimes middle name or additional surnames)
being Soares.
People are listed in the family view under their (principal) surname.

Clearly the tooltip of surname must be changed to so as to indicate
one can use Secondary, to add the additional surnames.
As indicated in the bug listing, in some cultures the additional
surname is at the front, and for other countries at the back of the
surname list, so 'middle' name would be wrong for some anyway.

Benny

> I have also added an option to some of my reports to replace the given
> name with the call name, so I can print a report with "Simone Müller"
> and "Alma Höfler", which is how these people are called usually.
>
> Thanks,
> Reinhard
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Reinhard Müller
Am Mittwoch, den 09.09.2009, 10:46 +0200 schrieb Benny Malengier:
> It is the middle surname, not a part of the given names.

That clears it up, thanks for explaining, and sorry for the confusion.

Reinhard

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Julio Sánchez-2
In reply to this post by Benny Malengier

2009/9/9 Benny Malengier <[hidden email]>

Clearly the tooltip of surname must be changed to so as to indicate
one can use Secondary, to add the additional surnames.
As indicated in the bug listing, in some cultures the additional
surname is at the front, and for other countries at the back of the
surname list, so 'middle' name would be wrong for some anyway.

The problem is that just as the first surname can have prefixes, so does the second surname.  For instance in Sánchez de la Torre, "Sánchez" is the first surname, and "De la Torre" is the second surname, but it should sort under "T".  If this was the first surname, "de la" would have gone into the surname prefix, but for later surnames there is no way to handle it.  Still worse, in "Santiago Ramón y Cajal", "Ramón" is the first surname and "Cajal" is the second surname.  "y" is a connector that is not part of either, but was required by law when the Civil Register was introduced and in many contexts is necessary for the name to be correctly parsed (since Ramón is also a given name).  BTW, this is the name of a Nobel Prize winner and his name is always written (in Spanish) exactly like that.

Besides, sources often show three or four surnames.  This does not happen currently but genealogy is mostly about the past.

In PhpGedView they have made a reading of GEDCOM 5.5 that allows things like:

1 NAME Cándida /Sánchez de la Torre/
2 GIVN Cándida
2 SURN Sánchez, Torre

1 NAME Santiago /Ramón y Cajal/
2 GIVN Santiago
2 SURN Ramón, Cajal

So, essentially, they have a field that holds the name "formed in the manner the name is normally spoken, with the given name and family name (surname) separated by slashes" (this is GEDCOM 5.5 wording). And SURN holds the bare surnames.  The NAME line is computed by default from the parts, but this mechanism can be overridden.

I don't think I quite like it (and my copy of PGV is patched to my precise liking that deviates in minor ways from it), but seems (for Spanish) superior to all the alternatives except to those that insist that separate input fields for exactly two surnames is an absolute must for a genealogy application (ignoring that before late 19th century most people had exactly one surname).  The downside is that *nothing* more advanced than Notepad interoperates usefully with it.  You can find the bare data for a test I did at:

http://www.enredo.es/surname-handling-survey/

A number of voluntaries submitted the result of processing:

http://www.enredo.es/surname-handling-survey/original-PGV.ged

with their genealogy program of choice.  All programs lost part of the information in the original.

BTW, in the Spanish-speaking world, genealogists use the suffix field for a second surname (vide program GDS that does that explicitly, but PAF and others can be abused to achieve it), but I find that extremely unsatisfactory.

Regards,

Julio


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Josip-3
In reply to this post by Benny Malengier
Benny Malengier wrote:

> 2009/9/9 Doug Blank <[hidden email]>:
>> 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!
>
> I don't like the comma idea.
>
> If this is realized, then it should be accompanied with a plugin
> 'Clean Names'. This would allow to have multiple surnames split into
> middle name and surname. It would also make the conversion from
> present values to new values easier. The plugin should follow the
> concept of first viewing the changes that would happen, with actual
> change only after clicking accept or continue.
>
> Nickname could also be seen as 'another name', as it is not really
> part of the name. But I understand the rationale of having it.
> If I remember correctly, somewhere in the past, the label Callname was
> changed to the label Nickname because anglosaxon names had no use for
> it, but then as it became clear the translations where wrongly
> translating the field to nickname, instead of callname (and users of
> those locales asking how to store the callname), the english label was
> reverted back to indicate 'Callname'.
> So it's not that nickname was removed, it was that making it official
> that the same field could be used for two different things lead to
> problems.
>
> To conclude, for me it is good to add both these fields as official
> fields to the name editor and person editor.
> In the person editor, I would suggest to add a new line for these
> fields at the top, so that the organization is:
>
> Family:                      Suffix/Prefix
> Given:                        Call Name:
> Middle:                       Patronymic/Title:
> Type:                         Nick Name:
>
> Rationale for this: Call name is a part of the given name that is the
> call name, so should be on the same line as Given.
> Middle name is for many people empty, so should be on the third line
> instead of between Family and Given.
>
> If people think Middle name should be with Patromic/Title on line 2,
> because that is the more logical thing, then let it be known.
>

Now users are forced to enter names in the way gramps wanted it and
change the way in which is they later displayed but should be other way
around: insert the names in your natural order and instruct gramps how
to use them.

As for nicknames i would like to see two type: personal and family
nicknames. That would be "unofficial" names now but back then they are
"official" in sense people are registered with them as addition to real
name, both real and nickname, or just one of them.

Like to see more types of names added (could add few "unofficial" more)
because it is not problem in 100 unneeded options but in 1 missed.

--
Josip

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Nick Hall-6
In reply to this post by Peter Landgren
I have only a couple of quick comments.

When I started to use gramps I wanted to include a nickname for some
people. This would often be a short form of the first given name or
perhaps the second given name (in full or shortened). I decided to use
the "Call Name" field but never knew if this was really the correct way
to use it. There can be more than one way to do things in gramps which
can be confusing for new users.

In reports, it would be nice to be able to either include the nickname
in quotes between the given names and family name, or in brackets after
the name. If there is no nickname for the person then I don't want to
see empty quotes or brackets.

In English the term middle name usually refers to a given name other
than the first. An alternative label would be better.

Changing the tooltip for "Given name" to "Given name(s)" is a good idea.

Nick.

Peter Landgren wrote:

> Den Wednesday 09 September 2009 09.39.40 skrev Benny Malengier:
>  
>> 2009/9/9 Doug Blank <[hidden email]>:
>>    
>>> 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!
>>>      
>> I don't like the comma idea.
>>
>> If this is realized, then it should be accompanied with a plugin
>> 'Clean Names'. This would allow to have multiple surnames split into
>> middle name and surname. It would also make the conversion from
>> present values to new values easier. The plugin should follow the
>> concept of first viewing the changes that would happen, with actual
>> change only after clicking accept or continue.
>>
>> Nickname could also be seen as 'another name', as it is not really
>> part of the name. But I understand the rationale of having it.
>> If I remember correctly, somewhere in the past, the label Callname was
>> changed to the label Nickname because anglosaxon names had no use for
>> it, but then as it became clear the translations where wrongly
>> translating the field to nickname, instead of callname (and users of
>> those locales asking how to store the callname), the english label was
>> reverted back to indicate 'Callname'.
>> So it's not that nickname was removed, it was that making it official
>> that the same field could be used for two different things lead to
>> problems.
>>
>> To conclude, for me it is good to add both these fields as official
>> fields to the name editor and person editor.
>> In the person editor, I would suggest to add a new line for these
>> fields at the top, so that the organization is:
>>
>> Family:                      Suffix/Prefix
>> Given:                        Call Name:
>> Middle:                       Patronymic/Title:
>> Type:                         Nick Name:
>>
>> Rationale for this: Call name is a part of the given name that is the
>> call name, so should be on the same line as Given.
>> Middle name is for many people empty, so should be on the third line
>> instead of between Family and Given.
>>
>> If people think Middle name should be with Patromic/Title on line 2,
>> because that is the more logical thing, then let it be known.
>>
>> Benny
>>
>>    
> Sounds fine with me, as long as we keep the 'Call Name', which is important for Swedish users.
>
> I have another database field question:
> In the Repository View the is a column called 'County', but there is no way to get information into
> that column. At least I can't. Is there e field for the county in the database? If not we should
> delete the column or if there is a field we should add it to the address editor.
>
> /Peter
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Frederico Munoz
In reply to this post by Julio Sánchez-2
Hello,

I already said quite a bit in the bug thread. My position at this time
is that the feature is very useful, but that it isn't as simple to
implement as I first expected.

Julio's  overall post is excellent in fleshing out many of the details
and possible problems. The situation he describes is similar for
Portugal, except that the ordering of the surnames is different ( It's
Given Name | Mother Surname(s)| Father Surname(s) )

2009/9/9 Julio Sánchez <[hidden email]>:
(...)
> BTW, in the Spanish-speaking world, genealogists use the suffix field for a
> second surname (vide program GDS that does that explicitly, but PAF and
> others can be abused to achieve it), but I find that extremely
> unsatisfactory.

As do I, this is something that I think should be avoided like the
plague. It sounds like a good idea until one tries to make something
with the data and reports don't work, other people have trouble with
the data we send them, etc.

In Portugal most of the people I know end up simply using the "Given
Name" field as a "Everything but the last name" one. This because the
last name is the one that is inherited by children (well, most of the
time, once one reaches the 17th century all bets are off, real
patronymics appear, etc). For my Spanish ancestors I add the last
surnames and then use the Group as feature (example: Name: Santiago
Family Name: Ramón y Cajal  Group As: Ramón).

BTW, the idea of putting every surname in the Family Name is
semantically more correct, but extremely bothersome to use and
somewhat detached from the way surnames actually work.

I'll leave the implementation details to the developers. In general
terms the proposal to add a "general" field to enter the surnames is
something that I find sensible, with the following requirements:

- GEDCOM export should be straightforward. The flattening of the
surnames should have very clear and simple rules
- The data entry dialog should be easy to use

Additionally I'm unsure how GEDCOM import would work out.

Having said that this is something that is lacking in just about every
Genealogy software out there, and is something that stems from the
lack of support in GEDCOM, that assumes that every surname is "equally
important", possibly because where the LDS is at most people only have
one surname. However IIRC there is at least some additional
flexibility when using programs which use the "/" delimiter for family
names, since the location of it in the name becomes a non-issue
(important for Spanish names).


Regards,

Frederico

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Benny Malengier
2009/9/10 Frederico Muñoz <[hidden email]>:

> Hello,
>
> I already said quite a bit in the bug thread. My position at this time
> is that the feature is very useful, but that it isn't as simple to
> implement as I first expected.
>
> Julio's  overall post is excellent in fleshing out many of the details
> and possible problems. The situation he describes is similar for
> Portugal, except that the ordering of the surnames is different ( It's
> Given Name | Mother Surname(s)| Father Surname(s) )
>
> 2009/9/9 Julio Sánchez <[hidden email]>:
> (...)
>> BTW, in the Spanish-speaking world, genealogists use the suffix field for a
>> second surname (vide program GDS that does that explicitly, but PAF and
>> others can be abused to achieve it), but I find that extremely
>> unsatisfactory.
>
> As do I, this is something that I think should be avoided like the
> plague. It sounds like a good idea until one tries to make something
> with the data and reports don't work, other people have trouble with
> the data we send them, etc.
>
> In Portugal most of the people I know end up simply using the "Given
> Name" field as a "Everything but the last name" one. This because the
> last name is the one that is inherited by children (well, most of the
> time, once one reaches the 17th century all bets are off, real
> patronymics appear, etc). For my Spanish ancestors I add the last
> surnames and then use the Group as feature (example: Name: Santiago
> Family Name: Ramón y Cajal  Group As: Ramón).
>
> BTW, the idea of putting every surname in the Family Name is
> semantically more correct, but extremely bothersome to use and
> somewhat detached from the way surnames actually work.
>
> I'll leave the implementation details to the developers. In general
> terms the proposal to add a "general" field to enter the surnames is
> something that I find sensible, with the following requirements:
>
> - GEDCOM export should be straightforward. The flattening of the
> surnames should have very clear and simple rules
> - The data entry dialog should be easy to use
>
> Additionally I'm unsure how GEDCOM import would work out.

As GEDCOM has no provision for it, there is no way it can be included
and made to work.
There is no reason to do GRAMPS --> GEDCOM --> GRAMPS
So adding new fields to GEDCOM only GRAMPS knows adds no value. Time
is better spend cleaning up import of GEDCOM which would just keep the
names as stored, and add new ones present in the GEDCOM.

As a consequence, the way to support it, is to import names as now
from GEDCOM (with addition for support of nickname that is present in
GEDCOM) and offer a plugin tool 'Cleanup names' that can batch process
names so as to split up surnames.
That tool should eg allow for:
* split multiple surnames as <secondary surname> <primary surname>
* split multiple surnames as <primary surname> <secondary surname>

I am only unclear in how to handle the binding y. Is it ok to consider
this a prefix? Probably not, but then the y should be part of
secondary surname field, so as to make printing work correctly. I
would think it is not too much of a bother to have that there if you
want it, after all, you know what it means.

Adding a field (surname combine field) just for the 'y' looks like
overkill to me. The usage will be so specific per culture, with
probably some exceptions too.....
The idea previously that surname is like 'name, nome', and this
automatically goes to 'name y nome' would not work in general either.

Benny

> Having said that this is something that is lacking in just about every
> Genealogy software out there, and is something that stems from the
> lack of support in GEDCOM, that assumes that every surname is "equally
> important", possibly because where the LDS is at most people only have
> one surname. However IIRC there is at least some additional
> flexibility when using programs which use the "/" delimiter for family
> names, since the location of it in the name becomes a non-issue
> (important for Spanish names).
>
>
> Regards,
>
> Frederico
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Julio Sánchez-2

2009/9/10 Benny Malengier <[hidden email]>
2009/9/10 Frederico Muñoz <[hidden email]>:

> I'll leave the implementation details to the developers. In general
> terms the proposal to add a "general" field to enter the surnames is
> something that I find sensible, with the following requirements:
>
> - GEDCOM export should be straightforward. The flattening of the
> surnames should have very clear and simple rules
> - The data entry dialog should be easy to use
>
> Additionally I'm unsure how GEDCOM import would work out.

As GEDCOM has no provision for it, there is no way it can be included
and made to work.

What GEDCOM has support for is multiple surnames.  They are separated by commas in the value of the SURN tag.  No such provision is there for the NAME tag, so leaving the commas there is arguably not permitted by GEDCOM.

So, no matter how it is arranged in fields in GRAMPS, export to GEDCOM should use commas in SURN and expect them on import.  GRAMPS may optionally support other things, but that is what GEDCOM requires.
 
There is no reason to do GRAMPS --> GEDCOM --> GRAMPS

This was the only way to copy a set of people (defined with a filter) from one GRAMPS database to another, since XML export did not use filters.  Does it now?  I have myself done that gazillions of times.
 
So adding new fields to GEDCOM only GRAMPS knows adds no value. Time
is better spend cleaning up import of GEDCOM which would just keep the
names as stored, and add new ones present in the GEDCOM.

As a consequence, the way to support it, is to import names as now
from GEDCOM (with addition for support of nickname that is present in
GEDCOM) and offer a plugin tool 'Cleanup names' that can batch process
names so as to split up surnames.
That tool should eg allow for:
* split multiple surnames as <secondary surname> <primary surname>
* split multiple surnames as <primary surname> <secondary surname>

It may help in some cases.  But it is in general undecidable.  Each surname may contain multiple words and even humans can't get it right everytime without context.  Humans should be able to express the correct way to parse names.

An example, in a name like "García Álvarez de Toledo y Carrillo de Toledo":
  • How should it be parsed?  How many surnames are in it?  Well, García is a given name that is now seen only as a surname, but things were different in the past.  It seems that "Carrillo de Toledo" would be a second surname, but there are other problems.
  • Is "Álvarez" a real patronymic?  This means García is the child of some Álvaro (possibly "de Toledo", but no guarantee).  His children will probably use the "Garcés" (or even "García") as patronymic and, possibly, "de Toledo" as surname.  This scheme was valid until ca. 1200.  In this case, Álvarez should go into the patronymic field or, as is common, as part of the given names.  "de" would go into the surname prefix field.
  • Is "Álvarez" a false patronymic?  In this case, his father was not Álvaro, but he got his name (given plus patronymic) from some ancestor or relative of notice named "García Álvarez" (not necessarily "de Toledo").  In this case, the best coding is probably the same as for real patronymics except that context does not help a lot.  This is after ca. 1200.
  • Is it a non fixed part of the surname?  It is a dark period where patronymics start being inherited but they have not solidified.  In this case, García's father was "Álvarez de Toledo" but some of Garc'ia's siblings would be just "de Toledo", as would some of his children.  Some of them might even have a different patronymic.  In this case, IMHO, I think it is best to put all of "Álvarez de" as surname prefix.  Otherwise it would sort García under "A" and only an amateur would want that.
  • Is it a solidified part of the surname?  In this case "Álvarez de Toledo" is uniformly inherited as a block and exceptions are rare.  All of it should go into the surname (and sort under "A").
This is not a made-up name, artificially obfuscated.  It is the name of a real person, namely, the first Duke of Alva.  Unskilled humans are bad at parsing many of these names, so you get to hear a lot of silliness.

I think I have now vigorously scratched the surface of the Spanish name parsing problem.  Problem is that most people who understand the issues know very little of computers.  And those who understand computers have never seen a facsimile of a document as recent as the 19th century.

I am only unclear in how to handle the binding y. Is it ok to consider
this a prefix? Probably not, but then the y should be part of
secondary surname field, so as to make printing work correctly.is I
would think it is not too much of a bother to have that there if you
want it, after all, you know what it means.

Adding a field (surname combine field) just for the 'y' looks like
overkill to me. The usage will be so specific per culture, with
probably some exceptions too.....
The idea previously that surname is like 'name, nome', and this
automatically goes to 'name y nome' would not work in general either.

Well, I said 'y' as just an example.  It can be 'e' too, depending on context.  And in Catalan names, 'i' is used instead.  The connector may also be a comma, especially if there are more than two surnames.   Did this get weird enough already?

If you never try to do anything intelligent with the second surname, like indexing, sorting or exploiting them in some way, you can just leave the connector and prefixes with the following surname.  But as soon as you try to do something smart with them...  If your program does smart things with later surnames, you have no choice but leaving out the connector completely.

The beauty of what they have done in PGV is how simple it is and how much mileage you can get from something this simple.   BTW, they did not do it specifically for Spanish, there are pathological cases in other cultures where this is a win, but can't remember the particulars.

Best regards,

Julio



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Frederico Munoz
In reply to this post by Benny Malengier
Hello again,


2009/9/10 Benny Malengier <[hidden email]>:
> 2009/9/10 Frederico Muñoz <[hidden email]>:
(...)
>> Additionally I'm unsure how GEDCOM import would work out.
>
> As GEDCOM has no provision for it, there is no way it can be included
> and made to work.
> There is no reason to do GRAMPS --> GEDCOM --> GRAMPS
> So adding new fields to GEDCOM only GRAMPS knows adds no value. Time
> is better spend cleaning up import of GEDCOM which would just keep the
> names as stored, and add new ones present in the GEDCOM.

Indeed, I was not aiming at doing some "smart" importing, since at
least around here  it would likely be very difficult to do and with
less than stellar results.

>From Julio's latter message though it seems that at least there are
some valid ways that some might use (the SURN tag) that could have
some impact, but this is something more general (i.e. assuming that
what PGV did is valid GEDCOM how will GRAMPS handle the importing
*today*).


> As a consequence, the way to support it, is to import names as now
> from GEDCOM (with addition for support of nickname that is present in
> GEDCOM) and offer a plugin tool 'Cleanup names' that can batch process
> names so as to split up surnames.

Yes, a plugin could be e good idea, since it would leave to the
individual the choice.

> That tool should eg allow for:
> * split multiple surnames as <secondary surname> <primary surname>
> * split multiple surnames as <primary surname> <secondary surname>

Right.

> I am only unclear in how to handle the binding y. Is it ok to consider
> this a prefix? Probably not, but then the y should be part of
> secondary surname field, so as to make printing work correctly. I
> would think it is not too much of a bother to have that there if you
> want it, after all, you know what it means.

>From Julio's latest example one can see that this can get rather complex.

> Adding a field (surname combine field) just for the 'y' looks like
> overkill to me. The usage will be so specific per culture, with
> probably some exceptions too.....

True, which is why aiming at something more general is, if at all
possible, better, since trying to provide input fields for every
details will in the end be overkill and could even be a limiting
factor given the wide array of choices.

Regards,

Frederico

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Duncan Lithgow-5
I think that although the ideal solution may have been suggested, I'm
probably not the only one who is confused and lost. If I start a wiki
table on the website will people help me populate it please?

First step would be a list with examples, next step would be trying
various table headings to see what works for the data best.

I'm not going to go through all the emails and bug thread myself... (I
don't have this issue much myself)

Duncan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Frederico Munoz
Hi,

2009/9/10 Duncan Lithgow <[hidden email]>:
> I think that although the ideal solution may have been suggested, I'm
> probably not the only one who is confused and lost. If I start a wiki
> table on the website will people help me populate it please?

Sure.

> First step would be a list with examples, next step would be trying
> various table headings to see what works for the data best.
>
> I'm not going to go through all the emails and bug thread myself... (I
> don't have this issue much myself)

I have some examples in the bug thread, I'll add them to the wiki when it is up.

Regards,

Frederico

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Duncan Lithgow-5
In reply to this post by Duncan Lithgow-5
2009/9/10 Frederico Muñoz <[hidden email]>:
> I have some examples in the bug thread, I'll add them to the wiki when it is up.

http://www.gramps-project.org/wiki/index.php?title=Names_Discussion

I think I got up to comment 0010695 on the bug tracker, but really
don't understand the issue well.

Duncan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Frederico Munoz
Hi,

2009/9/10 Duncan Lithgow <[hidden email]>:
> 2009/9/10 Frederico Muñoz <[hidden email]>:
>> I have some examples in the bug thread, I'll add them to the wiki when it is up.
>
> http://www.gramps-project.org/wiki/index.php?title=Names_Discussion
>

Adding stuff right now.

> I think I got up to comment 0010695 on the bug tracker, but really
> don't understand the issue well.

Sometimes I feel the same. I swing between wanting something and
thinking to myself that it's better to leave it all alone.

BTW, not directly concerned with this subject but I would be happy to
chat with GRAMPS users and developers in the #gramps channel, so if
anyone is interested drop by.

Regards,

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Benny Malengier
Ok, I was thinking a 'surname connector' field might be interesting after all

So,
Santiago Ramón y Cajal
would be
given:                      Santiago
surname:                 Ramon
secondary surname: Cajal
surname connector:  y

And the format string [Given] [prefix] [Surname] [Suffix] [Surname
connector] [Secondary Surname]

But then I read:
José de Mascarenhas da Silva e Lencastre
The e is a connector right? But not between surname and secondary
surname, so that would be:
given:                      José
surname:                 Mascarenhas
prefix:                      de
secondary surname: da Silva e Lencastre
surname connector:

So the connector cannot be used, and the fact that da is a prefix to
surname Silva cannot be stored specifically.

And also: García Álvarez de Toledo y Carrillo de Toledo
given:                      García
surname:                 Álvarez de Toledo
prefix:
secondary surname: Carrillo de Toledo
surname connector:  y

Am I correct in my understanding? Is this sufficiently flexible.
The only other way would be to not store a surname, but store a
surname list, which would be like a table of surnames, of which one is
the primary surname, eg

José de Mascarenhas da Silva e Lencastre

would in table form be stored:
order    prefix    surname           suffix    primary?    connector to next?
1          de       Mascarenhas     /             Y                   N
2          da       Silva                  /             N                   Y
3          /         Lencastre           /             N                   N

That would be a very different way of input, and would store
everything and be flexible. Obviously only one name can have primary
indicator 'Y'

Benny

2009/9/10 Frederico Muñoz <[hidden email]>:

> Hi,
>
> 2009/9/10 Duncan Lithgow <[hidden email]>:
>> 2009/9/10 Frederico Muñoz <[hidden email]>:
>>> I have some examples in the bug thread, I'll add them to the wiki when it is up.
>>
>> http://www.gramps-project.org/wiki/index.php?title=Names_Discussion
>>
>
> Adding stuff right now.
>
>> I think I got up to comment 0010695 on the bug tracker, but really
>> don't understand the issue well.
>
> Sometimes I feel the same. I swing between wanting something and
> thinking to myself that it's better to leave it all alone.
>
> BTW, not directly concerned with this subject but I would be happy to
> chat with GRAMPS users and developers in the #gramps channel, so if
> anyone is interested drop by.
>
> Regards,
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Julio Sánchez-2

2009/9/11 Benny Malengier <[hidden email]>

And also: García Álvarez de Toledo y Carrillo de Toledo
given:                      García
surname:                 Álvarez de Toledo
prefix:
secondary surname: Carrillo de Toledo
surname connector:  y

Am I correct in my understanding?

In this case, it should not sort under "Álvarez", but under "Toledo".  See:

http://es.wikipedia.org/wiki/Garc%C3%ADa_%C3%81lvarez_de_Toledo_y_Carrillo_de_Toledo
 
Try to make sense of the Spanish version, the English version lacks detail.  Notice many of his children did not have the "Álvarez" part, even notice a daugther Mencía Enríquez de Toledo, i.e. she took a different patronymic from the maternal branch.  So "Álvarez" should be considered a non-indexing part of the surname, i.e. part of the surname prefix.

Patronymics are now just common surnames, they are inherited from parents.  So they should be recorded in the surname.  But earlier they fit better in the prefix and before that as a patronymic or as part of the given name if a specific field is not available.

I am not alone in this opinion.  For example, at the Historical Diocesan Archive of the San Sebastian Diocese they have completed indexing their books and they set as a guideline that before 1800, patronymics should be recorded with the given name instead of the surname:

http://mendezmende.org/artxiboa/kontsulta/AyudaSacramental.htm

That makes sense in Guipuzcoa.  In other places it is difficult to set a specific date.  1800 looks too recent for me as a general rule.

Is this sufficiently flexible.

For most, it is.  I mean, most users and most researched individuals.  However, cases exist where I'd like to have more flexibility:  For instance, in reading page 64 of the 4th volume of Solares Montañeses by Mateo Escagedo Salmón, I find that José Gregorio Ceballos el Caballero (that's just one surname, BTW) married "Maria Venancia Dávalos de Rivera Mendoza Mate de Luna y Córdova".  From the context I make the educated guess that those are four sunames:  Dávalos de Rivera, Mendoza, Mate de Luna and Córdova.  It would be nice to record that, especially since there is no explanation in the source of that "Mate de Luna", that flags the possibility that the source is wrong or an interesting line of research.
 
The only other way would be to not store a surname, but store a
surname list, which would be like a table of surnames, of which one is
the primary surname, eg

José de Mascarenhas da Silva e Lencastre

would in table form be stored:
order    prefix    surname           suffix    primary?    connector to next?
1          de       Mascarenhas     /             Y                   N
2          da       Silva                  /             N                   Y
3          /         Lencastre           /             N                   N

That would be a very different way of input, and would store
everything and be flexible. Obviously only one name can have primary
indicator 'Y'

I personally prefer the list because: a) grows as needed and b) shrinks as needed.

Best regards,

Julio


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposals for additional name fields

Frederico Munoz
In reply to this post by Benny Malengier
Hi,

2009/9/11 Benny Malengier <[hidden email]>:
> Ok, I was thinking a 'surname connector' field might be interesting after all
(...)
> And the format string [Given] [prefix] [Surname] [Suffix] [Surname
> connector] [Secondary Surname]
>
> But then I read:
> José de Mascarenhas da Silva e Lencastre
> The e is a connector right? But not between surname and secondary

You are correct (that's the 8th Duke of Aveiro btw, who met a most
gruesome death), there are 3 connectors in that name: "de", "da" and
"e".

> surname, so that would be:
> given:                      José
> surname:                 Mascarenhas
> prefix:                      de
> secondary surname: da Silva e Lencastre
> surname connector:
> So the connector cannot be used, and the fact that da is a prefix to
> surname Silva cannot be stored specifically.

Correct, but at this point I'm thinking that finding a way to deal
with the "main" surname in terms of prefix is good enough (i.e. I
don't think that a solution for this should be postponed until some
method that individually categorises every single name and particle is
found). In my research I have found (in Portugal and Spain) some
highly irregular patterns of surname inheritance, especially pre-1800,
with someone inheriting the surname from his mother who got it from
her paternal grandfather (while her father sported his mother
surname), etc. There is also a lot of patronymic/matronymic
"artifacts" in second names, etc.

All this to say that a solution that deals with the "main surname" vs.
"all others" is good enough IMO.


> And also: García Álvarez de Toledo y Carrillo de Toledo
> given:                      García
> surname:                 Álvarez de Toledo
> prefix:
> secondary surname: Carrillo de Toledo
> surname connector:  y
>
> Am I correct in my understanding? Is this sufficiently flexible.
> The only other way would be to not store a surname, but store a
> surname list, which would be like a table of surnames, of which one is
> the primary surname, eg
>
> José de Mascarenhas da Silva e Lencastre
>
> would in table form be stored:
> order    prefix    surname           suffix    primary?    connector to next?
> 1          de       Mascarenhas     /             Y                   N
> 2          da       Silva                  /             N                   Y
> 3          /         Lencastre           /             N                   N
>
> That would be a very different way of input, and would store
> everything and be flexible. Obviously only one name can have primary
> indicator 'Y'

If I'm understanding it correctly... I find this approach flexible
enough, elegant enough and powerful enough to deal with
exports/imports.

In general terms Julio's comments have more depth than mine, and he is
certainly more experienced, so I think that if we can find something
that works for the examples shown we're set. There is always the
question on how to present the input forms for the user (not a minor
point in terms of usability).

As an interesting detail I've recently saw dynastree Home Edition (a
branded and changed version of the free software Windows program
Ahnenblatt) and they introduced a "middle name" input box (see
http://www.dynastree.com/resources/images/he-screenshot2.png). I
experimented with in under Wine (crashed during GEDCOM export :/ ) and
to be honest I don't fully understand what they are doing. The "Last
Name" input box seems to produce no effect at all. I mention this not
as something to emulate, merely to show that this seems to be
something that others are also having a go at.

I'll try to add more to the GRAMPs wiki if something comes to mind.

Regards,

Frederico

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...