New Nick Name Fields

Nick Name

A field for a nick name is added. Many people like to store nick name as part of the name, while now it can only be stored as an attribute. Many people use callname, but that is wrong use of that field. The Nick Name is for a nick name of a single person and will be a new name field.

Family Nick Name

A field for a nick name used to indicate the family.

Definition: In some cultures, when a family name is common, family
nicknames are used on documents to indicate the specific branch.
Sometimes these family nicknames are even used on legal documents.

Examples: mountain villages in Switserland, Austria, Dalmatia. Sometimes a family nickname becomes an official name after some time.

Question: Is this a good English word for this practice?

Minor User interface changes

Relabel Given Name

Given name is relabelled in the UI as Given name(s).

Validate Callname

Callname becomes a validated field (like eg date, longitude). That is, it becomes red if the callname is not present in the given name(s).

What is the problem?

Let's discuss: 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ía'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").

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.

Proposed Solution: surname list

The proposal is to introduce:

In the UI and not editable: Formatted Name. This is a field indicating the full name as given upto now. So it has the same function as the title bar now in the person editor. However, the format is fixed and not changeable: given names - surnames. This field is to give a quick overview of the total name

In the UI and not editable: Sort Name. This is the field indicating on what the name is normally sorted in the grouped view and some reports. This field shows or the primary surname, or the group name if that is set. This field is to give a quick overview of how the name will be sorted.

Surname list: the surname consist of a list of surnames. The user sets prefix, type, connector as per his desires. One surname must be set as the primary surname. Note that surname does not have a suffix, that remains a global name field (used for eg Junior or The Third).

Quick data entry. We do not want to slow down entry of names for people with simple names. Therefore, the user interface shows all options of a single surname, and the user can add extra surnames via an add button.

Patronymic is deprecated. It becomes a type of surname (a boolean value). At the same time, Matronymic [3] is added. This is stored in a derivation field, indicating how the name came about: inherited (assumed default), patronymic, matronymic, ... . What others??

With many surnames, users quickly want to know if a surname is derived from the family of the mother, or from the family of the father. Mother side, Father side allow to indicate this.

Details

Example of the surname list:

Formatted Name: José de Mascarenhas da Silva e Lencastre

Sort: Mascarenhas

order

prefix

surname

primary?

connector to next?

derivation

1

de

Mascarenhas

Y

inherited

2

da

Silva

N

e

inherited

3

Lencastre

N

inherited

surname field: de Mascarenhas da Silva e Lencastre

Changes from previous designs:

no mother side field or father side field: This can be shown in UI by scanning the parents. No need to store it as that will lead to conflicts

NAME_PIECE_PREFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_PREFIX>, <NAME_PIECE> ]
Non indexing name piece that appears preceding the given name and surname parts.
Different name prefix parts are separated by a comma. For example :
Lt. Cmndr. Joseph /Allen/ jr.
In this example Lt. Cmndr. is considered as the name prefix portion.

NAME_PIECE_SUFFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_SUFFIX>, <NAME_PIECE> ]
Non-indexing name piece that appears after the given name and surname parts.
Different name suffix parts are separated by a comma.
For example :
Lt. Cmndr. Joseph /Allen/ jr.
In this example jr. is considered as the name suffix portion.

NAME_PIECE_SURNAME: = {Size=1:120}
[ <NAME_PIECE> | <NAME_PIECE_SURNAME>, <NAME_PIECE> ]
Surname or family name. Different surnames are separated by a comma.

NAME_PIECE_SURNAME_PREFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_SURNAME_PREFIX>, <NAME_PIECE> ]
Surname prefix or article used in a family name. Different surname articles are separated by a comma,
for example in the name "de la Cruz", this value would be "de, la".

Examples of NAME_PERSONAL:
William Lee (given name only or surname not known)
/Parry/ (surname only)
William Lee /Parry/
William Lee /Mac Parry/ (both parts (Mac and Parry) are surname parts
William /Lee/ Parry (surname imbedded in the name string)
William Lee /Pa.../

GEDCOM has support for 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. Hence, SURN should contain all surnames, seperated by a comma.

PhpGedview has an extension to the name field that otherwise is not supported, should we follow it?:

1 NAME Cándida /Sánchez de la Torre/

2 GIVN Cándida

2 SURN Sánchez, Torre

Suggested workflow for export from Gramps

all surnames are given to the SURN field divided by comma's

name field corresponds to the Formatted Name as seen in Gramps, with slashes (/) around the surnames

title is exported to NPFX

primary surname prefix and suffix go to SPFX, NSFX.

As a consequence, a lot of information is lost on Gedcom export (callname, which is the primary name, connector), but all of the surname _is_ present in the NAME field.

Suggested workflow for import from Gramps

all surnames in SURN (divided by comma's) are an entry in the surname list of Gramps

NAME field is parsed identifying the surname piece. All before a name goes to prefix of the surname behind it, what comes at the end goes to suffix of the last surname. If SPFX, NSFX is given, the surname that corresponds with that in name is set primary name, and prefix/suffix updated as needed

if primary surname cannot be identified, the first one is set primary.

User Interface

Present surname use

Surname now appears in display as and in sort as and in the preferences for name. The meaning of surname in those context would become the complete compound surname. If needed an extra format can be added: 'primary name'? This is to investigate further...

Name Editor

The name editor must be reworked. Most important is that the new facilities for compound names do not slow down data entry of normal common surnames (that is eg German, English). So no listview is given for the list of compound names, instead the primary surname is fully shown with all fields, and a list is shown under it in those cases that a compound name is present or wanted. To work out further...

Add buttons: obtain surnames from father, mother, child. On clicking these the surname list is added with those of the father, mother, child (no intelligent merging done). The father side is checked in case of father, mother side in case mother.

When a person is selected in the person view, and add person is clicked, the surname list is generated with that of the selected person.

Do we allow copy/paste of surname? For that we need a list where we can copy from/to. This will depend on the final design of the editor. Surname will be an object, so adding copy/paste is straightforward.

Compound Name Parser Tool

A tool is written than can parse the first primary surname, and split it up in surname parts. This is to do the conversion from 3.2 to 3.3. The tool might also provide for the use-case of storing surname in given name, so parsing given name to add surnames to the surname list.

Upgrade

Upgrade from 3.2 to 3.3 database should be straightforward, with the exception of the disappearance of patronymic.

In 3.2 there is one surname, prefix, suffix, so this becomes the first (and primary) surname

if patronymic is given, there are the following possibilities

patronymic given, no surname. Patronymic becomes the first surname in the surname list, it is primary, and patronymic

patronymic is given and equal to surname. This reduces to the case above.

patronymic is given, surname is given, and they are not equal. This is a wrong use of the user or a user using patronymic as part of a compound surname. We always assume the last. The surname becomes the first surname and is primary. The patronym becomes the second surname and is set patronymic.