Family Historian User Group

davidf wrote: ↑

18 Jun 2022 13:26

How much is it our role to think through first what "adequately handle a variety of non (English) standard name structures" actually means and second what are possible ways forward (with pros and cons)?

If we want to discuss it, it's our role, within the skillsets we have (and acknowledging that we probably don't have all the background knowledge needed).

ColeValleyGirl wrote: ↑

18 Jun 2022 14:02

davidf wrote: ↑

18 Jun 2022 13:26

How much is it our role to think through first what "adequately handle a variety of non (English) standard name structures" actually means and second what are possible ways forward (with pros and cons)?

If we want to discuss it, it's our role, within the skillsets we have (and acknowledging that we probably don't have all the background knowledge needed).

Is there a way to "poke" all users to draw their attention to a discussion (a facility that probably should not be used too frequently - only with Admin approval?)? If so we might formulate (on a separate thread linked to this) an appeal for examples of difficult name structures. I somehow suspect that Non-English-1st-language users might not naturally be drawn to a thread with this title; I suspect many English first language speakers may be uncertain about the intricacies of SPFX vs NPFX!

davidf wrote: ↑

18 Jun 2022 14:41

Is there a way to "poke" all users to draw their attention to a discussion

No, and I'm not convinced it's necessary. I'll retitle this topic.

From the GEDCOM v5.5.1 document the surname prefix is defined as:

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"

One of the biggest issues with surname and surname prefix in a “singular surname” environment is the “when in time and where in the world” when a surname was used.

By this I mean, at different times and places a prefix was actually a prefix vs other times/places the surname actually was part of the surname. An example is a name like “van Zant”, sometime written as “Vanzant” or “VanZant” or “Vanzandt”.

At one point in history the name “van Zant” was not a surname but a topographic name “of/near a cliff”, later it became a surname sometime index under “v” and other times under “z” depending on we’re you lived at the time!

So for these type of individuals, sometimes “van” is a legitimate surname prefix (read as of/near) while other times the “van” is actually the surname either as “Vanzant” or as “van Zant”, this depends on the know history of the name for that location, but unfortunately many family historians have not research name histories well enough to make the right call on when the value is a prefix or a surname.

Just my educated thoughts!

tatewise wrote: ↑

18 Jun 2022 12:03

...
The attached Match Name with Components plugin Version 0.4 Date 18 Jun 2022 attempts to deal with some of the other issues raised.
It has a user dialogue to adjust how the updates are performed.
It disregards the Name Prefix (NPFX) component.
Note that it now not only operates on the Primary Name fields but also the Alternate Name fields.

If only one Individual has any Name fields changed then the plugin will only list that in the Result Set to allow manual adjustments via the Property Box.

This is getting clever - almost too clever as the first time I ran it it did the opposite to what I expected (re precedence)

Trying to work through an example on my "inherited" file (1) Run the plug in (precedence for Name and exclude NSFX) and I get: Not what I want! Back out (Undo) and
(2) run again (precedence for Parts and exclude NSFX) and I get: Which is more like it, but that alternate name should have been slashed! Edit and
(3) rerun again (precedence for Parts and exclude NSFX) and I am where I want to be.

Run (1) with "Precedence for Name" rather than using the name to define the parts seemed to destroy the Name!
Run (2) with "Precedence for Parts" - which I expected to overwrite the NAME with the combined parts, didn't do that but did appear to make the NAME the primary record and the parts the secondary records with the parsed NAME populating the parts.

Scope for confusion?

I never want the Name Prefix Suffix* in the Name - vanilla FH has them separate so I keep them separate. Remembering to deselect the checkbox is a bit of a gotcha - can the choice be made persistent (if it even has to remain - do we want the Name prefix to effect sorting by Given Name*)?

Thanks it is a useful data maintenance tool - but I still have a wish for a "mainstream way to enter and edit names where I want them to sort on a part of the Surname"!

* Edit after reply from Mike
----
For reference (Mike knows this word for word, but I suspect he is near unique)

https://gedcom.io/specifications/ged551.pdf

GIVN {GIVEN_NAME}
A given or earned name used for official identification of a person.

NAME {NAME}:=
A word or combination of words used to help identify an individual, title, or other item. More than one NAME line should be used for people who were known by multiple names.

NPFX {NAME_PREFIX}:=
Text which appears on a name line before the given and surname parts of a name.
i.e. (Lt. Cmndr.) Joseph /Allen/ jr.
In this example Lt. Cmndr. is considered as the name prefix portion.

NSFX {NAME_SUFFIX}:=
Text which appears on a name line after or behind the given and surname parts of a name.
i.e. Lt. Cmndr. Joseph /Allen/ (jr.)
In this example jr. is considered as the name suffix portion.

SPFX {SURN_PREFIX}:=
A name piece used as a non-indexing pre-part of a surname

SURN {SURNAME}:=
A family name passed on or used by members of a family. [by implication this is the indexing part of a surname]

KFN wrote: ↑

18 Jun 2022 15:27

From the GEDCOM v5.5.1 document the surname prefix is defined as:

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"

having just quoted from https://gedcom.io/specifications/ged551.pdf p92 (part of Appendix A: Lineage-Linked GEDCOM Tag Definition):

SPFX {SURN_PREFIX}:=
A name piece used as a non-indexing pre-part of a surname

Your quote (also found in the same document p56 in the section "Primitive Elements of the Lineage-Linked Form") had me slightly confused - particularly the reference to comma separation.

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

From the same section has me even more confused.

The indexed/non-index distinction is I think key and in part answers your temporal questions re van Zant and VanZant and I think in the end highlights the dangers of a plug-in to try and accurately and consistently parse the /Surname/ in the Name field - although the Current version of Mike's plug-in will parse:

1. van Zant as Prefix: van & (indexable) Surname: Zant
2. Van Zant, VanZant and Vanzant as (indexable) Surname: Van Zant / VanZant / Vanzant

(1) above I suspect is "right" - although a previous comment about differences between Dutch and Flemish speaker may disagree - and you highlight changes over time!
(2) may be "right" in terms of wanting to index the entire surname - but would you want the indexing to take account of the space and capitalisation?

I've not considered the spelling variation Vanzandt - it will be a complete surname but do we want it to index as a "standardised" Vanzant? GEDCOM does not have a "Standardised (Indexable) Surname" Tag (?). But then does GEDCOM have a "Standardised Place Name"? (Not with an s in -ised - or a z!) FH however does!

I think you are pushing for "user decision (or indication) at input", you want to be able to enter van Zant and specify on a case by case basis whether indexing is on Zant, or van Zant or even vanZant (or who knows on van - some one (far eastern?) will come up will a name structure of Surname+SurnameSuffix?). And is case-sensitive indexing important?

A GEDCOM processor would require the indexable bit in one field and the rest in another field - it can handle the rest being in the SPFX field but there is no SSFX field to handle the indexing on van case. (Arguably you might say that indexing on van Zant achieves the same end - but you may want the GIVN field to be the secondary sort prior to the Zant)

So a requirement (per Adrian's nudge!) is to be able to easily* enter/edit surnames in such a way that indexable and non-indexable parts can be put in the appropriate fields to enable most GEDCOM processors (especially FH - but also including those processors to which we may outwardly migrate) to index the Surnames appropriately?

* i.e. not via the "All tab"!

KFN wrote: ↑

18 Jun 2022 15:27

..., but unfortunately many family historians have not research name histories well enough to make the right call on when the value is a prefix or a surname.

Which of course is the justification for throwing the whole thing into a single NAME field!

Whoops
In haste I got the Name and Parts options reversed in the plugin.

David, you started talking about excluding NSFX, but later referred to Name Prefix (NPFX) that the plugin disregards.
Do you actually use Name Suffix values?
i.e. Put anything into the INDI.NAME.NSFX field or add text in the NAME field after the 2nd slash /?
If not then the plugin 'Include (NSFX) Name Suffix ?' option has no impact.

Yes, the settings can be made 'sticky' but I need to confirm the options are rational before taking that step.

The attached plugin fixes the reversed options.

tatewise wrote: ↑

18 Jun 2022 17:57

Whoops
In haste I got the Name and Parts options reversed in the plugin.
...
The attached plugin fixes the reversed options.

Thanks, I was getting worried that the brain fog was reaching me early!

tatewise wrote: ↑

18 Jun 2022 17:57

David, you started talking about excluding NSFX, but later referred to Name Prefix (NPFX) that the plugin disregards.

Ah, you mean ...

I never want the Name Prefix in the Name - vanilla FH has them separate so I keep them separate.

I should have said Name Suffix (although actually I mean both). I would not want suffix data appended to the NAME field - staying vanilla etc.

tatewise wrote: ↑

18 Jun 2022 17:57

Do you actually use Name Suffix values?
i.e. Put anything into the INDI.NAME.NSFX field or add text in the NAME field after the 2nd slash /?
If not then the plugin 'Include (NSFX) Name Suffix ?' option has no impact.

Yes, the settings can be made 'sticky' but I need to confirm the options are rational before taking that step.

I use the Name Suffix (and Prefix) fields on the Property Box More ... dialogue and I have also inherited NAME fields with text after the second slash - but often what is there is more "nickname" or Title than true Suffix.

If the logic you had written was to take stuff after the second slash and put it in the Suffix field I can see why you included it if it was things like "Donald /Trump/ Jnr" or "Donald /Trump/ III" I can see the value in parsing that out (and possibly back in?). What would you do with "Dai /Jones/ the post"?

I very rarely come across that (possibly unusual) - a few "Jnr" s in my One-name American orphan project. In My British Project unless an individual was known at the time as "John Smith jnr" I don't use it - I might have a custom attribute recording Genealogical ID: "William Willett (the younger) of Daylight Saving Fame" or "William Willett (the elder) founder of the Building firm" - but that is to help me distinguish them!

In my European Ruling Family File I have some Roman Numbers at the end - sometime after a slash - but they usually belong appended to the end of the Given Name (Henry VIII etc.)

So for me I would want that option either default to off or for my choice to be persistent.

I'll probably add the 'sticky' settings feature next week.

Also, bear in mind that the Precedence for name or Parts: option only comes into play when both the Name field and the included component Parts have values and they disagree.
If the Name is empty then Parts is the temporary precedence for that name structure.
If the Parts are all empty then Name is the temporary precedence for that name structure.

KFN wrote: ↑

18 Jun 2022 15:27

... unfortunately many family historians have not research name histories well enough to make the right call on when the value is a prefix or a surname. ...

In fairness, it can be next to impossible to make the right call at any particular point in time. As an example - not of a prefix, I must say - take a discussion I was part of in a local history Facebook group. The gent in question was named Charles John Bowen Cooke and my colleague remarked that railway enthusiasts normally refer to loco designs by the surname of their (nominal) chief designer, e.g. Churchward, Gresley or Stanier locos. But, he said, enthusiasts refer to Bowen Cooke designs even though he didn't have a hyphenated, double barrelled name.

When I dug into Ancestry records, the evidence appeared muddled as to whether his surname was Cooke or Bowen Cooke (no hyphen). I even found two signatures from the man himself on applications for membership of the engineering institutes - one said CJ Bowen Cooke and the other CJB Cooke - with only a few years between them!

That's why I'm quite happy to just have one data item with the ability to insert the // characters to delineate the family name and add Alternate Names. Generally speaking I can fudge the odd instances like the above with notes. But my fudging one or two names is rather different from others dealing with a cascade of names not in the classic English form.

Before you jump to conclusions, I started this topic (I'm the OP) with:

Kaaskop wrote: ↑

16 Jun 2022 08:48

I'm still a TMG user but looking for a new program.

Suggestion like "The OP wants to continue working as close to the way they were accustomed to work as possible" or "they want FH to be like TMG" are not true!
I'm looking for something new because TMG don't satisfy me anymore.
My name is Reinoud van Wijk, I have over sixty years experience with the "van" in my name. You don't only sort on the "W" but search on it also. I guess 40% of the names in the Netherlands has at least a surname prefix and/or a complex surname. Sorting and searching on "van" isn't a option (By the way: TMG isn't that good in handling the surname prefix).

But the Gedcom specifications for example 5.5.1 and 7.08 give the possibility to use the Personal Name Structure and because Family Historian use and follow the Gedcom standard, I hoped to find in FH my new program. So I was a bit disappointed when I started with FH. With the help from this forum and specially Mike (thank you), who wrote the plugin, I see the possibilities of FH.

I don't believe in "one size fits all" but if the standard gives you the possibility to use separate name-parts, why shouldn't you give the user the choice how to use them?
Of course CP makes the choice if they will keep their focus on the Englisch speaking part of the world or broaden their focus to more cultures.

Kaaskop wrote: ↑

18 Jun 2022 19:41

Suggestion like "The OP wants to continue working as close to the way they were accustomed to work as possible" or "they want FH to be like TMG" are not true!

Apologies that I misunderstood your intent, but I still think we need a wide-ranging discussion about all the aspects of the requirements to handle structured names outside the 'Anglo-Saxon' norm.

I did mention a custom property box tab that would improve the data entry of the various name parts. Is that something that would be of interest? -- if so, we can talk you though creating it.

Kaaskop wrote: ↑

18 Jun 2022 19:41

Suggestion like "The OP wants to continue working as close to the way they were accustomed to work as possible" or "they want FH to be like TMG" are not true!

Helen has apologised for going down the above route, but I think I am the prime offender - possibly reacting to the (valid) suggestion that we were looking for "solutions" rather than trying to understand "requirements". So I'll add my apologies; I'm sorry.

Kaaskop wrote: ↑

18 Jun 2022 19:41

...
I'm looking for something new because TMG don't satisfy me anymore.
My name is Reinoud van Wijk, I have over sixty years experience with the "van" in my name. You don't only sort on the "W" but search on it also. I guess 40% of the names in the Netherlands has at least a surname prefix and/or a complex surname. Sorting and searching on "van" isn't a option (By the way: TMG isn't that good in handling the surname prefix).

But the Gedcom specifications for example 5.5.1 and 7.08 give the possibility to use the Personal Name Structure and because Family Historian use and follow the Gedcom standard, I hoped to find in FH my new program. So I was a bit disappointed when I started with FH. With the help from this forum and specially Mike (thank you), who wrote the plugin, I see the possibilities of FH.

I don't believe in "one size fits all" but if the standard gives you the possibility to use separate name-parts, why shouldn't you give the user the choice how to use them?
Of course CP makes the choice if they will keep their focus on the Englisch speaking part of the world or broaden their focus to more cultures.

(My emboldenings)

Calico Pie have always made a "thing" about GEDCOM compatibility, so we can probably safely assume that they are trying to guess the direction and rate of roll out of future GEDCOM standards - the Personal Name Structure (ref: https://gedcom.io/specifications/ged551.pdf page 38) is on the horizon if the current direction is maintained.

ged551.pdf wrote:Based on the dynamic nature or unknown compositions of naming conventions, it is difficult to provide more detailed name piece structure to handle every case. The NPFX, GIVN, NICK, SPFX, SURN, and NSFX tags are provided optionally for systems that cannot operate effectively with less structured information. For current future compatibility, all systems must construct their names based on the <NAME_PERSONAL> structure. Those using the optional name pieces should assume that few systems will process them, and most will not provide the name pieces.

A <NAME_TYPE> is used to specify the particular variation that this name is. For example; if the name type is subordinate to the <NAME_PERSONAL> it could indicate that this name is a name taken at immigration or that it could be an ‘also known as’ name (see page 56.)

Future GEDCOM releases (6.0 or later) will likely apply a very different strategy to resolve this problem, possibly using a sophisticated parser and a name-knowledge database.

That is not as encouraging as I would like and leaves the ground open to how individual developers will appeal to the market.

As Reinoud said CP have the option to "broaden their focus to more cultures" and I would feel that is essential for competitiveness - which is a major determination of the survival and future development of existing software. There is a feeling that the Genealogy market in the Anglosphere (in this instance broadly UK/Ireland, Canada/USA, Australia/New Zealand) is becoming saturated - witness the fall off in events (pre-COVID) - will we see them picking up again? The scope for expansion (and more software sales) has to be in one or both of the following directions.

1. Countries with disposable income and spare time not already saturated - which means much of Europe, parts of South America, Middle East, Parts of Asia (South, South East and East) and Parts of Africa - most of which are not "English as a first language" countries - and even if they might be used to English Language software, they will be trying to enter "home country" data which is not English!
2. The Genealogical "deep divers" in their existing markets - for instance, Americans who want to get back to their pre-migration ancestors who may have been German, Swedish, Irish etc.

So I would agree with Helen

ColeValleyGirl wrote: ↑

18 Jun 2022 19:50

... but I still think we need a wide-ranging discussion about all the aspects of the requirements to handle structured names outside the 'Anglo-Saxon' norm.
...

Then we might be able to give CP a nudge possibly to accelerate their thinking about particular areas - this being an area that if not big to us (Anglo-Saxons) individually is big to the future genealogy market. I doubt if 2% of the names in my main research project have surname prefixes, so it's an irritation that I manually handle, but if it was 40% that would be a serious problem. I suspect that there are some relatively easy first wins that might gain CP market share in the non English speaking world - which would then give them a wider user base from which to draw ideas for further development.

@Helen and David,
Thank for your reaction. You don't have to apologize there is nothing wrong with your valuable input. The discussion you are having is much more important then why I want to change from program.
Let's be honest CP would be crazy to rewrite their software for one foreign user. On the other hand they would also be crazy when they don't listen to their experienced users who are discussing the future of FH and the possibilities on that route.

Kaaskop wrote: ↑

19 Jun 2022 10:28

...
Let's be honest CP would be crazy to rewrite their software for one foreign user. On the other hand they would also be crazy when they don't listen to their experienced users who are discussing the future of FH and the possibilities on that route.

Ah, but would they be (rewriting for one foreign user)?

FH (like others) is very much written for the (original) Anglo-Saxon market, it has attracted predominantly "English as a first Language" users researching Anglosphere families - so on this forum we have to be conscious that we may be moderately representative of Anglosphere genealogists - but not necessarily of all genealogists or potential genealogists.

Has genealogy as a mass pursuit always been Anglo-spheric? The French, Spanish, Portuguese and to a lesser(?) extent the Dutch, Belgians, Italians and Germans have all had empires (presumably with associated emigration and diasporas); has that generated an interest in Family History? Even without the impact of empires the history of many European Countries (or areas that have "moved" between countries) is interesting and is there a large body of people interested in how their families wove their way through for instance the process of German or Italian integration?

Have those interested just put-up with or struggled with English language software and Online Database (and DNA) Services - or are we just unaware of foreign language software and services? (I am aware of Ancestris software and https://www.arkivdigital.net/ - which covers Swedish records - but their home page is in English - presumably to attract 3rd/4th generation Swedish immigrants to the US?)

And what about Non European originated genealogy? I think of the interest developed by the Roots TV program (forename /surname/ is probably not a helpful name structure there!) How far back in various cultures do we have to go before "surname" becomes problematic?

How far back in various cultures do we have to go before "surname" becomes problematic?

Easy - 1 generation. I remember an Indian-born colleague telling me that she grew up with no surname, and used her father’s name as her surname when she moved to the US.

ColeValleyGirl wrote: ↑

18 Jun 2022 19:50

I did mention a custom property box tab that would improve the data entry of the various name parts. Is that something that would be of interest? -- if so, we can talk you though creating it.

I have now the Given, Prefix and Surname field in the property box. I can put name parts in the fields i want, and the plugin
combines them to the name.
I don't know what you mean by "a custom property box tab" but like to learn more.

How far back in various cultures do we have to go before "surname" becomes problematic?

If you are Icelandic you have a problem today, in general they don’t have an inheritable surname since they are on the patronymic naming standard. In Norway it was not a requirement to have an inheritable surname until 1924, my rural family members born before that date were also on the patronymic naming standard as well. Many naming customs today include multiple surnames as well which may have non-surname parts between the surnames!

If you are researching a family whose names follow the (a?) patronymic naming standard - which I take to mean taking your father's name (with or without variable endings) so the name does not persist down the father's line in the same way that a surname does - how do you like to index/group/search for individuals and how would you want to select them in dialogue boxes that require you to select an individual?

I am struggling to understand how you cope with a Given Name + Patronymic Name + Family Name structure (as in Russia). From the Wikipedia page on "Patronymic":

In Russia, the patronymic is an official part of the name, used in all official documents, and when addressing somebody both formally and among friends.[24][25] The correct written order of a full name is surname, given name, then patronymic – this order would be found on official documents, business cards, and formal addresses. For example, a woman named Mariya Iosifovna Zhukova would hand you a business card that says Zhukova Mariya Iosifovna. Use of the given name followed by the patronymic in Russian is always the neutral, correct and polite way to address any person except close friends, family members, or children – in such cases usage of the patronymic adds humor intonation. This form would be congruent to the Western use of Mr. and the surname for the polite and proper use and reference. Instead of schoolchildren calling their teacher Ms. and surname, the proper form would be given name and patronymic. For example, a teacher named Anna Iosifovna Yelchina would always be called Anna Iosifovna by her pupils. When addressing a much younger person, only the first name is commonly used. Individuals are addressed by their given name followed by the patronymic (e.g., "Mikhail Nikolayevich") in many situations including on formal occasions, by colleagues at work, by acquaintances, or when being addressed by someone younger in age.[24][26] It is becoming more common for younger individuals (under 50) to drop the patronymic at work.[26] In informal situations, if a person is called by a diminutive (such as Misha for Mikhail or Nastya for Anastasia), the patronymic is not used.[25]

In colloquial, informal speech, it is also possible to contract the ending of a patronymic: thus Nikolayevich becomes Nikolaich, and Stepan Ivanovich becomes Stepan Ivanych or simply Ivanych as the given name may be omitted altogether. In this case, the contraction, if possible, is obligatory: Ivan Sergeyevich Sidorov may be called "Sergeich" or, more rarely, "Sergeyevich". In contrast to male names, if a woman is called by her patronymic name without a given name, the patronymic is usually not contracted: "Ivanovna" but "Mar' Ivanna"; "Sergeyevna"/"Sergevna" is one exception, where both forms are fine. Typically, a patronymic name alone is a familiar form of addressing an older female.

With that amount of variability in selecting which parts to use, a naive non-native researcher seeing a name for the first time might struggle to work out what they have got - never mind how you allocate it to a Given Name + Patronymic Name + Family Name structure - before "force fitting" it to the GEDCOM Given Name + Surname Prefix + Surname structure! (Remember the Surname Prefix is defined as a non-indexable element of the surname).

AdrianBruce wrote: ↑

18 Jun 2022 19:37

When I dug into Ancestry records, the evidence appeared muddled as to whether his surname was Cooke or Bowen Cooke (no hyphen). I even found two signatures from the man himself on applications for membership of the engineering institutes - one said CJ Bowen Cooke and the other CJB Cooke - with only a few years between

I hear you on this example, and I agree that some specific instances are hard to discern, in particular when they are out of the general cultural norm! In this case, without any research for this discussion what so ever, I might have looked to see if his birth mother was named Bowen before marriage! I recall that Hiram Ulysses Grant (a US President) went by the name Ulysses Simpson Grant, where Simpson was his mother’s birth name! So yes, to be fair, these individuals were outside the general custom at the time to inherit a surname from the father, and took a variation to use a well known surname from their mother as well! Hyphenation was not a cultural option then, nor was having two surnames, but including as an identifier to a well know (wealthy) mother’s family was popular among some groups!

Reading current American obituaries I get the impression that it is quite widespread for women on marriage to "move" their maiden surname to be a final Given-name before taking their husband's name.

So (Mrs) Judith Anne Miller /Smith/ was (Miss) Judith Anne /Miller/ before marriage and not Judith Anne Miller /MaidenSurname/

The GEDCOM Name_Type may in the future help handle this [ref https://gedcom.io/specifications/ged551.pdf p56] - but I do wish you could apply a date to the Name_type (as you can to the TITL Title tag) so you could keep track of changing usage through an individual's life.

Kaaskop wrote: ↑

19 Jun 2022 12:00

ColeValleyGirl wrote: ↑

18 Jun 2022 19:50

I did mention a custom property box tab that would improve the data entry of the various name parts. Is that something that would be of interest? -- if so, we can talk you though creating it.

I have now the Given, Prefix and Surname field in the property box. I can put name parts in the fields i want, and the plugin
combines them to the name.
I don't know what you mean by "a custom property box tab" but like to learn more.

If you have them in the property box already, you don't need a custom tab. (but you can use the same techniques you used to add them to an existing tab to create a completely new tab).

Another tip, however -- if you're going to run the plugin often, you might find it useful to add it to the Tools menu.

Tools > Plugins > select the plugin > More > tick Add to Tools Menu > Close.

Now look at the Tools menu -- the plugin is listed there.

AdrianBruce wrote: ↑

18 Jun 2022 19:37

...
The gent in question was named Charles John Bowen Cooke and my colleague remarked that railway enthusiasts normally refer to loco designs by the surname of their (nominal) chief designer, e.g. Churchward, Gresley or Stanier locos. But, he said, enthusiasts refer to Bowen Cooke designs even though he didn't have a hyphenated, double barrelled name.

When I dug into Ancestry records, the evidence appeared muddled as to whether his surname was Cooke or Bowen Cooke (no hyphen). I even found two signatures from the man himself on applications for membership of the engineering institutes - one said CJ Bowen Cooke and the other CJB Cooke - with only a few years between them!

It's not as if there are clear rules!

Sometimes a full "worded" name (particularly 4 or more names - such as Charles John Bowen Cooke) is just being comprehensive, but at other times with 3 names you end up wondering.
Ralph Vaughan Williams is Ralph /Vaughan Williams/, but Simon Russell Beale is, I believe, actually Simon Russell /Beale/ - even though I don't think anyone refers to him as Simon Beale (may be an Equity naming thing?).

Likewise one might guess that a name written as CJ Bowen Cooke is actually CJ /Bowen Cooke/ but it could be an attempt to highlight that the preferred Given Name is Bowen!

AdrianBruce wrote: ↑

18 Jun 2022 19:37

That's why I'm quite happy to just have one data item with the ability to insert the // characters to delineate the family name and add Alternate Names. Generally speaking I can fudge the odd instances like the above with notes. But my fudging one or two names is rather different from others dealing with a cascade of names not in the classic English form.

I think that is a very good reason for continuing with a single NAME field - with or without piece parts. That at least ensures that you don't end up searching on a field with a whole load of blanks - and that an export to a less comprehensive program will get the essence of the name. FH is pretty good at searching for a fragment of a Given Name or a Surname, so if we have the name Reinoud /van Wijk/, searching for Wijk in a "surname field" will search NAME:SURNAME and correctly return Reinoud /van Wijk/

Maintaining both the single NAME field and the GIVN+SPFX+SURN requires careful management (particularly around the add/amend name routines) - which in the end I think has to be main-code (via a wish list request or an autonomous decision by CP) rather than a plug-in.

Maintaining a NAME field (even if only programmatically NAME=GIVN+SPFX+SURN) makes diagrams and reports easier (for instance with common report layouts and text schemes etc rather than separate text schemes for "Single field users" and "Piece Part field users") at least as far as how the result looks. In terms of ordering the people in a report though, a sort on NAME:SURNAME may not necessarily do what "international" users want.

(I don't know the process for lobbying in respect of GEDCOM but I do wonder, if they have introduced the slash convention (given /surname/), might they not introduce further delineators so you could input, for instance, Reinoud /~van~ Wijk/ or further to indicate patronymics (e.g. /Zhukova/ Mariya *Iosifovna*) etc.? The standard talks about "Future GEDCOM releases (6.0 or later) will likely apply a very different strategy to resolve this problem, possibly using a sophisticated parser and a name-knowledge database." - it may be necessary to give the parser a few hints due to the sheer variety of forms - or even to over-ride the name-knowledge database.)