* Surname prefix (SPFX) -- more generally, handling structured names.

[tatewise]

I'm wondering why you have to write a plugin to get the Prefix and Surname from the Name. This information is already in the Gedcom file. Why not read the Gedcom? Will FH write it to Gedcom or stay SPFX and SURN empty?

I'm not sure what you mean by "this information is already in the Gedcom file".
Your earlier screenshot for Name: Dirk Cornelisz /van Wijk/ clearly shows the Prefix SPFX and Surname SURN are empty.
If data is already in the GEDCOM SPFX and SURN tags, then it will be in the FH Project SPFX and SURN fields, and the Plugin will make no changes.
It is not so easy for a Plugin to read the GEDCOM file, but as I've just said, the same data is in FH anyway.
Any changes to any fields in FH, including SPFX and SURN, will get saved to the GEDCOM file.
Unlike other products, the GEDCOM file is the FH database. Any change to one also changes the other.

It may be that you are still climbing the learning curve to understand the concepts of how FH operates.

[Kaaskop]

I made a few test imports this morning and found:
1. Gedcom made with TMG including Prefix and Surname tags, import in FH: the Prefix and Surname will show in the property box.
2. Import directly from TMG: Prefix and Surname don't show. These tags are in the FH Gedcom not present. So FH don't read/import those tags from TMG.

If I add a new person in FH by a given name, prefix an surname doesn't make the NAME tag, it stays blanc. So if you want to add a person you have to fill in the Name: field.

It feels like the reverse way: giving in the whole name and then breaking it apart in pieces. To me it feels more naturally to give the pieces and let the program compose the Name. IF FH can't do this automatically, is there als a plugin for?
Looking in the future, I found the Gedcom 7.0 specification. It was good to see that Calico Pie, according to FamilySearch, is committed to Adopting FamilySearch GEDCOM 7. In that specification I found on page 54: "meaning in particular that all name parts in PERSONAL_NAME_PIECES should appear within the <PersonalName> payload." In that case the question is will FH make the Name pieces standard in the property box?

Breaking names in pieces introduce mistakes. A few examples I found after using your plugin:
-Name: Ameijden van Duijm becomes given blanc, prefix Ameijden, surname van Duijm instead of: surname Ameijden van Duijm
-Name: van der Most van Spijk, Jacoba becomes given Jacoba, prefix van, surname der Most van Spijk instead of: given Jacoba, prefix van der, surname Most van Spijk.
-Name: Herfst van Tilborgh, Adrianus becomes given Adrianus, prefix Herfst, surname van Tilborgh instead of: given Adrianus, prefix blanc, surname Herfst van Tilborgh.
-Name: van der Tier, Anthonie becomes given Anthonie, prefix van, surname der Tier instead of: given Anthonie, prefix van der, surname Tier

As you see prefixes can consist multiple parts or also be part of the surname (or combined), I can't give you a list there are to much of them.
This is why i prefer to have seperate fields in a program. And at the moment a plugin to compose the name field (tag) from the pieces, I think that's more reliable.

Don't mistake my input for negativity, I'm very positive! FH works as you intended and good, but this Forum, the reaction, thinking in solution and the quick reactions are superb! Together it gives me an experience I have not had with any other developper, Thanks!

[Jane]

Just to clarify, none of the people who have been helping you work for Calico Pie. They are "just" users like yourself.
This site is separate to Calico Pie and not run or funded by them.

[davidf]

It feels like the reverse way: giving in the whole name and then breaking it apart in pieces. To me it feels more naturally to give the pieces and let the program compose the Name.

For "simple Anglo" names Forename [Forename] Surname inputting directly into a single field has its benefits (for instance, cutting and pasting) - the program merely assumes the last part is the Surname. It starts to get ragged with compound surnames; hyphenated ("double-barrelled") surnames it can handle via looking for the space, but it comes to grief with names like Ralph Vaughan Williams (an English C20th composer), so you have to use the "slash convention" and explicitly enter that name as Ralph /Vaughan Williams/. A bit clunky but it retains the ease of entry for "simple Anglo" names

Breaking names in pieces introduce mistakes. A few examples I found after using your plugin:
-Name: Ameijden van Duijm becomes given blanc, prefix Ameijden, surname van Duijm instead of: surname Ameijden van Duijm
-Name: van der Most van Spijk, Jacoba becomes given Jacoba, prefix van, surname der Most van Spijk instead of: given Jacoba, prefix van der, surname Most van Spijk.
-Name: Herfst van Tilborgh, Adrianus becomes given Adrianus, prefix Herfst, surname van Tilborgh instead of: given Adrianus, prefix blanc, surname Herfst van Tilborgh.
-Name: van der Tier, Anthonie becomes given Anthonie, prefix van, surname der Tier instead of: given Anthonie, prefix van der, surname Tier

Have you tried entering the above examples (which with my very limited knowledge of name structures I find hard to follow) using the "slash convention" to "mark" the "surname" (being the surname prefix and the main surname) - the plug-in looks for the slashes to find which bit of the "name" to carve up. Are you also entering some/all as Surname, Forenames ? if so I think the slashes are definitely required.

As you see prefixes can consist multiple parts or also be part of the surname (or combined), I can't give you a list there are to much of them.

OK, so that rather blows my thoughts about a wish-list item that maintains a list of "prefixes" (due to the size of the list and it would fail on keeping Herfst van Tilborgh as a surname). You getting Herfst as a Surname Prefix, I think means you are using the first version of Mike's plug-in - the current version requires prefixes to start with a lower case letter.

That takes me back to the idea that - if we stick with being able to enter complete names in a single field - extending the "slash convention" and somehow delineating the parts of the surname.

Suppose
van der Most van Spijk, Jacoba is entered:
/~van der~ Most van Spijk/ Jacoba
That would enable a plug-in (or even future built-in code?) to parse the name field, finding the bit to be "chopped" /~van der~ Most van Spijk/, then within it finding the prefix ~van der~ and loading the prefix, surname and forename fields appropriately.

However for compatibility you don't want to save the tildas (~) (or whatever delineator is chosen) in the name line within the GEDCOM , so we require code to delete the non-standard delineators before save and to re-assemble the name field contents (with FH delineators) before display for edit. This really needs to be "main code" rather than plugin* - otherwise when-ever you want to edit a name (in the name field), you have to run the plugin first to stop an almighty muddle!

* Or we do have an ability to code a plugin to run on a given program event - such as "display property box" - but that is another potential wish-list item!

It may be that we have a wish-list item to be able to configure (in Preferences) whether we enter names via the "name" field or via separate "part fields" - almost like we can configure some internationalisation items?

[davidf]

David, it is known that loading libraries can be problematic with WINE.
Use the Install Library Modules plugin from the Plugin Store.
There is also an issue regarding 'utf8data' that my plugin may not have dealt with if you have downloaded the utf8 library previously.

Ok I will try that when the Plug-in store starts behaving (at the moment it looks as if it is suffering what I think of as failure to serve "Server Side Includes"):

Browse all Plugins

There are currently [frm-stats id=121 type=count value=”Approved”] plugins in the plugin store.

[display-frm-data id=13]

I will give it a while and report it to CP if necessary

[ColeValleyGirl]

Where are you seeing that error, David (Link?) I'm not seeing it.

[tatewise]

I made a few test imports this morning and found:
1. Gedcom made with TMG including Prefix and Surname tags, import in FH: the Prefix and Surname will show in the property box.
2. Import directly from TMG: Prefix and Surname don't show. These tags are in the FH Gedcom not present. So FH don't read/import those tags from TMG.

That seems to be a direct import error, so please report it to Calico Pie via http://www.calico-pie.com/osticket/open.php.

If I add a new person in FH by a Given Name, Prefix and Surname doesn't make the NAME tag, it stays blanc. So if you want to add a person you have to fill in the Name: field.

Yes, FH does not usually enter data into any fields automatically.
For most users, simply entering the Name field is enough and is easier than entering each component field.
A plugin could be written that compares the Name field against the component fields and fills in what is missing.

Breaking names in pieces introduce mistakes. A few examples I found after using your plugin:

Some of those examples have already been corrected in the plugin Version 0.2 attached earlier.
I will try and fix the other problems identified later today or tomorrow.

[davidf]

Where are you seeing that error, David (Link?) I'm not seeing it.

Yeah, Helen you got there before I did - an out-dated bookmarked link!
Used to be https://www.family-historian.co.uk/plug ... ll-plugins
now: https://pluginstore.family-historian.co.uk/
Thanks

[davidf]

David, it is known that loading libraries can be problematic with WINE.
Use the Install Library Modules plugin from the Plugin Store.
There is also an issue regarding 'utf8data' that my plugin may not have dealt with if you have downloaded the utf8 library previously.

Thanks that is now working for V6 under Wine

[Kaaskop]

Just to clarify, none of the people who have been helping you work for Calico Pie. They are "just" users like yourself.
This site is separate to Calico Pie and not run or funded by them.

Thank you, I wasn't aware of that. The more my appreciation for this community!

[Kaaskop]

Breaking names in pieces introduce mistakes. A few examples I found after using your plugin:
-Name: Ameijden van Duijm becomes given blanc, prefix Ameijden, surname van Duijm instead of: surname Ameijden van Duijm
-Name: van der Most van Spijk, Jacoba becomes given Jacoba, prefix van, surname der Most van Spijk instead of: given Jacoba, prefix van der, surname Most van Spijk.
-Name: Herfst van Tilborgh, Adrianus becomes given Adrianus, prefix Herfst, surname van Tilborgh instead of: given Adrianus, prefix blanc, surname Herfst van Tilborgh.
-Name: van der Tier, Anthonie becomes given Anthonie, prefix van, surname der Tier instead of: given Anthonie, prefix van der, surname Tier

Have you tried entering the above examples (which with my very limited knowledge of name structures I find hard to follow) using the "slash convention" to "mark" the "surname" (being the surname prefix and the main surname) - the plug-in looks for the slashes to find which bit of the "name" to carve up. Are you also entering some/all as Surname, Forenames ? if so I think the slashes are definitely required.
The parts before the comma "Ameijden van Duijm" "van der Most van Spijk" "Herfst van Tilborgh" and "van der Tier" are between slashes

It may be that we have a wish-list item to be able to configure (in Preferences) whether we enter names via the "name" field or via separate "part fields" - almost like we can configure some internationalisation items?

Yes, please!

[davidf]

Breaking names in pieces introduce mistakes. A few examples I found after using your plugin:
-Name: Ameijden van Duijm becomes given blanc, prefix Ameijden, surname van Duijm instead of: surname Ameijden van Duijm
-Name: van der Most van Spijk, Jacoba becomes given Jacoba, prefix van, surname der Most van Spijk instead of: given Jacoba, prefix van der, surname Most van Spijk.
-Name: Herfst van Tilborgh, Adrianus becomes given Adrianus, prefix Herfst, surname van Tilborgh instead of: given Adrianus, prefix blanc, surname Herfst van Tilborgh.
-Name: van der Tier, Anthonie becomes given Anthonie, prefix van, surname der Tier instead of: given Anthonie, prefix van der, surname Tier

Have you tried entering the above examples (which with my very limited knowledge of name structures I find hard to follow) using the "slash convention" to "mark" the "surname" (being the surname prefix and the main surname) - the plug-in looks for the slashes to find which bit of the "name" to carve up. Are you also entering some/all as Surname, Forenames ? if so I think the slashes are definitely required.

The parts before the comma "Ameijden van Duijm" "van der Most van Spijk" "Herfst van Tilborgh" and "van der Tier" are between slashes

I think that if you download the latest version (i.e. the last linked download in this thread) you will find an improvement as Mike has restricted the recognition of Surname Prefixes to the first item within the "slashes", provided they start with a lower case letter and do not exceed 4 characters in length. This will mean that "/Ameijden van Duijm/" will be recognised as a complete SURN as will "/Herfst van Tilborgh/". It will (currently) fail on "/van der Tier/".

It may be that we have a wish-list item to be able to configure (in Preferences) whether we enter names via the "name" field or via separate "part fields" - almost like we can configure some internationalisation items?

Yes, please!

This may be an alternative way round - but is non trivial as the preference will impact on all dialogues which allow entering or editing of a NAME. It rather depends on whether Calico Pie see this as the most effective way to add market appeal to "non Anglos" - which is their commercial decision. Probably a Version 8 feature rather than a Version 7.X feature!

Perhaps we may want the ability to "enter by parts" - possibly via the Name "more ..." link?

I would add that using a single name field does allow those of us who cannot parse the more complex non English names to "just bung 'em in as they are". I hear that Icelandic names can be a challenge to Anglos, so I suspect any change would have to be a preference rather than a complete change to "entering by parts"

How do I parse:
María de las Mercedes Licer y García
María del Carmen Martínez-Bordiú y Franco
Lulach mac Gille Coemgáin
Gruoch ingen Boite meic Cináeda
El Cid [call him properly "Rodrigo Díaz /de Vivar/"]

"Special Cases" still for Mike to Ponder!
Gilbert d'Avranches [treat the ' as a separator, but then for reassembly is the prefix d' or d or even de/du? - with special rules as to when you change it to d'?]

[tatewise]

I've rewritten the Plugin to perform two tasks simultaneously.

If the Name (NAME) field is empty then it constructs it from the Name Prefix (NPFX), Given Name (GIVN), Surname Prefix (SPFX), Surname (SURN), and Name Suffix (NSFX) fields if they exist. This is identified as a < Name update.

If those Name Prefix (NPFX), Given Name (GIVN), Surname Prefix (SPFX), Surname (SURN), and Name Suffix (NSFX) fields are all empty and the Name (NAME) exists then it sets the Given Name (GIVN), Surname Prefix (SPFX), and Surname (SURN) derived from the Name field. The Surname Prefix (SPFX) can be any number of short prefixes starting with a lower case letter.
It is not possible to set the Name Prefix (NPFX), and Name Suffix (NSFX) fields. This is identified as a Parts > update.

If the Name (NAME) field and the Name Prefix (NPFX), Given Name (GIVN), Surname Prefix (SPFX), Surname (SURN), and Name Suffix (NSFX) fields are not compatible then this is identified as a None update.

Try the attached Match Name with Components Version 0.3 Date 17 Jun 2022.

It should handle the FH V6 utf8 library installation much better.

[davidf]

Thanks that is an interesting approach

Are we sure that we want to build the Name prefix and Name Suffix into the NAME field (which is a departure from vanilla FH)?

Trying it on a predominantly internet downloaded file which has all sorts of oddities in it, I am finding that it does not quite do what I expected - particularly on subsequent runs after I had tried to tidy up the NAME field hoping that a subsequent run would would give me a better parse. To take a constructed example of a ruler of the kingdom of say Devon:

So Mike I in the NAME field, then run
In the first parse it put I into the Surname field and Mike into the Given field - as expected, but not what I wanted.

So I edit the NAME field to Mike I// and rerun - with no change (Update = None). I expected it to amend Given to Mike I and Surname to either blank (or possibly no field)

I edit to Mike I /of Devon/ and rerun - again with no change.

If I go to the all tab and delete the Surname and Given name fields and rerun - it does what I expect: Mike I in the Given Field and Devon in the Surname field with of in the Prefix.

If the Name (NAME) field and the Name Prefix (NPFX), Given Name (GIVN), Surname Prefix (SPFX), Surname (SURN), and Name Suffix (NSFX) fields are not compatible then this is identified as a None update.

The above would seem to indicate that this is working as you intended? For the None updates, am I in effect looking for an option to either force the parts to be compatible with the whole, or the whole to be compatible with the parts in order to progress? I think I want to force the former but the OP would probably want to force the later.

Trying an amended NAME Mike I /of the County of Devon/ it does what I expect once I have deleted the part fields with of the in the Surname-Prefix field.

I find the need to delete the part fields in order for the plug-in to up-date those fields (after a change to the NAME field) a limitation.

To me it seems sensible to do some manual editing of the NAME field before running the plug-in - but it is an iterative process. Manual edits could include:

• Cosimo de'Medici the Elder >> Cosimo /de' Medici/ the Elder
  but not /O'Connor/ >> /O' Connor/
• Gonzalo de Borbón y Dampierre >> Gonzalo /de Borbón y Dampierre/
• Henry I >> Henry I// or Henry 1 /of wherever/ [but that requires research and checking]

To expect the plug-in to automatically parse this would require CITT!

[tatewise]

As a first draft, I could not decide to handle cases where the Name and components had values that were incompatible.
Which should take precedence?
Should the Name value set the component values OR the component values set the Name value?
So I just flagged them as None to let the user sort it out.

I suppose an option to choose which should take precedence is a solution.

I am also in two minds about the Name Prefix and Suffix. Perhaps better if they are excluded from the process.

[davidf]

Whenever you have "two versions" of something keeping them in line and deciding how to maintain/edit them is problematic. Clarity about what is happening is then important.

The OP was originally wanting direct access via standard dialogues to the Surname-prefix and Surname fields (and the Given Field as a direct corollary) plus presumably to have all reports and diagrams assemble Given Names, Surname-Prefix and Surname in all places where FH uses Name (or to have a way to populate the Name field from the parts - but that may lose some of the nuances of say sorting names in a report).

That requires main-code modification - I think ideally as an "Internationalisation preference", because many (English language users) find the use of the single NAME field a convenience (and can use the "slash convention" to handle most problematic divisions between Given and Surnames). I think also some naming conventions may want to inhibit the default surnames when adding children - again as part of an "Internationalisation preference".

I think we would need to briefly consider whether handling Surname-Prefix and Surname is sufficient to handle the variety of naming patterns outside the Given Name/Surname pattern much of the English speaking world knows. We may be constrained by the GEDCOM specification. Perhaps others can outline how their native naming conventions fit to the GEDCOM restrictions of NAME = GIVN+SPFX+SURN. This must be documented somewhere - Rootstech?

In the absence of main code changes, we go down the work-around route - which probably means a plug-in. The question is how we would use it.

For most of my Family History work (predominantly English Language) I only have occasional surname prefixes, so I tend to think I would use the plug-in as part of a periodic maintenance routine, probably triggered by an awareness that I have been working on prefixed surnames or by realising that Surname Sorting needs attention and that I need to consider whether I have the correct prefixes (de or du, von or van etc.). I think I would try to ensure that I have got my slashes in the right place and then rely on the logic of the plug-in to do the separation. I may then directly edit the "odd balls" via the "All tab" - but then I don't want those directly edited odd-balls over-written by another run of the plug-in (or at least I need to be able to identify them so I can re-apply the "odd ball corrections").

For my Project on European Ruling Families (which I tend to have open when TV programs are talking about the intricacies of the English Civil War or Jacobite Claims to the throne - or similar issues in European History) use of a single NAME field (even with "slashes") has its limitations due to the large variety of Names and name structures. Direct access (as requested by the OP) to the Surname-prefix and Surname fields and the Given Field would allow me to try and make a "first guess" when entering new individuals - and to subsequently correct those guesses.

But that leaves me with what to do with the vast bulk of single NAME field individuals in the original inherited download (which may be analogous to the OP's import problem). My inclination is to try and do this systematically rather than on a name by name basis due to the huge numbers involved - which means I will try to do the job iteratively. What I can do to influence the plug-in is restricted to careful placing of slashes, ensuring correct case of prefixes (I don't think I have met any capitalised Surname-Prefixes) and inserting of blanks - again trying to use Search and Replace to make global changes (preferably without getting out the regular expressions crib sheet). In these instances I probably do want the plug-in to overwrite my previous "part fields".

As an aside do we need to consider the case I have seen in other "subjects" where we want to display one version of a field but to sort on a slightly different version of that field (case-sensitive/insensitive sorts come to mind)? In such cases we may display NAME, but sort on a SURN that is different from NAME:SURNAME - beyond the prefix issue? Surnames that take different forms for sons and daughters (Russian?) might be an example - where you want to sort to within family group. (Within the GIVN field - which might contain Louis VIII and Louis IX, there is also a "sort" issue - but let's leave GIVN alone for the time being!)

(Moving Name-prefixes to the Name-prefix field is also a separate operation - I use queries to try and flush out the major prefixes and then manually edit. I don't think I can even specify a plug-in to do this - even without thinking about when "Lord" or "King" might be genuine Given Names! I tend to fall back on my original ideas of "prefix lists" or extending the "slash convention".)

Can plug-ins work on just the "record in focus" and create and use dialogues? If so you could enter a name in the NAME field on a "best guess" basis, fire the plug-in which could attempt a parsing and present a dialogue with that initial attempt (or current field values?) in dialogue fields for Full Name, Given Names, Surname Prefix, and Surname values, so you can manually edit or just confirm prior to updating/creating the actual GIVN, SPFX, SURN fields and possibly updating the NAME field?

[tatewise]

David, I suspect some of the internationalisation features you mention are not easily resolved and are outside the scope of the OP request and the plugin.

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.

[Kaaskop]

I've rewritten the Plugin to perform two tasks simultaneously.

Try the attached Match Name with Components Version 0.3 Date 17 Jun 2022.

I did, nice work!
I did a new import from TMF and run the plugin, as far i have seen they are all correct!
Also when giving in Given name, prefix and surname the plugin constructed the right Name.

Thanks, this will help a lot.

[LornaCraig]

.... I think also some naming conventions may want to inhibit the default surnames when adding children - again as part of an "Internationalisation preference".

This is easily done via Tools > Preferences > General tab > Insert likely surname when adding children or fathers. (Apologies if you are already aware of this.)

[AdrianBruce]

...
I think we would need to briefly consider whether handling Surname-Prefix and Surname is sufficient to handle the variety of naming patterns outside the Given Name/Surname pattern much of the English speaking world knows. ... Perhaps others can outline how their native naming conventions fit to the GEDCOM restrictions of NAME = GIVN+SPFX+SURN. This must be documented somewhere - Rootstech?
...

There is no "must be documented", I'm afraid... I know from not-too-distant dialog in FamilySearch forums that FamilySearch FamilyTree are a long way from agreeing ways to handle even the sort of European names that end up in FamilySearch.

To throw in one instance that may or may not be remotely relevant to this thread - patronymics. Should they be entered into the "family name" (or whatever we want to call it)? One correspondent was adamant that she wasn't putting Welsh patronymics into the "family name" / "surname" part of a FamilySearch name. On the other hand, to me, this seemed a perfectly sensible place to put a name consisting of a list of family members. As an aside, it was far from clear to me that Welsh patronymics were particularly similar to Scandinavian patronymics because they were liable to accumulate (e.g. "ap Rhys ap Meredudd") - how does that repeat get analysed and encoded?

Somewhere I read about the collating sequences used by librarians and telephone directories, etc., and I'm fairly certain that in some countries "van Gogh" will get sorted with the "v" names and in others with the "G" names - and no, it wasn't blatant ignorance but probably did have a lot to do with frequency of occurance.

Which brings me to a concern I have with this thread. What are the end user requirements? Access to Surname-prefixes and all the rest of that isn't a requirement - it's a solution (which, in FH, may or may not satisify the requirements). If anyone feels their concerns are being dismissed by that statement, I apologise - but I have been burned by this confusion myself.

It seems to me that sorting is an important aspect of the requirements - does Vincent need to be sorted with "van" or with "Gogh"? Do spelling variations need to be sorted separately or together - and what is a spelling variation anyway?

How do names need to be presented in reports and charts? - that's another important requirement.

Another potential requirement - Is it important that children default to a certain "family name" when created in FH? (Currently the offspring of John Doe and Mary Roe default to a family name of Doe - not helpful if patronymics are involved)

It's perfectly logical that requirements may be satisfied in other software by access to the prefix and suffix items, etc. It's also perfectly possible that some aspect of FH may sabotage charting, sorting and reporting because it uses prefix, suffix, etc, differently. But we might not realise that without understanding the requirements.

Again, I apologise if this sounds like a critical review, but I feel it's important to bring out what isn't necessarily clear.

By the way, I doubt that there's any chance of an all-embracing requirement - but we might deduce requirements for a few cultures.

[mjashby]

Fully in tune with Adrian's comments especially:

"It seems to me that sorting is an important aspect of the requirements - does Vincent need to be sorted with "van" or with "Gogh"? Do spelling variations need to be sorted separately or together - and what is a spelling variation anyway? "

There appears to be no universally correct answer and my understanding is that in the Netherlands and some other countries "van Gough" would be indexed under "Gogh, van", but in dutch speaking Flanders; Belgium, South Africa and many other countries it would normally be indexed under "van Gogh". That's also before taking into account the differing spelling conventions that apply internationally which might also yield "Van Gogh", "vanGogh" or VanGogh"

Whatever conclusion you reach is fated to displease someone.

Mervyn

[tatewise]

The primary purpose of this thread was to satisfy the OP request of handling Surname-Prefix (SPFX) and Surname imported from TMG. It seems that objective has been achieved. The plugin was originally intended as a bespoke solution for the OP. Everything else is an elaboration taking the discussion much further and I'm unclear what it hopes to achieve.

What are the end user requirements? They have been stated by the OP.

Lorna has already addressed the option to: Insert likely surname when adding children or fathers.

The sorting of Names can mostly be handled by Records Window columns or custom Queries or maybe Plugins to deal with the cases not handled by the GEDCOM-based defaults. The specific sort rules will probably vary from user to user.

I am not aware of products that handle such sorting well, especially as many do not even fully support Unicode yet.
So it is not surprising that FH lacks some of those features. However, it does have user plugins that may offer a workaround

[davidf]

.... I think also some naming conventions may want to inhibit the default surnames when adding children - again as part of an "Internationalisation preference".

This is easily done via Tools > Preferences > General tab > Insert likely surname when adding children or fathers. (Apologies if you are already aware of this.)

I looked, but I did not see!

If we are thinking about making FH more international, possibly repeating this check box - "Insert father's name when creating children" - in V6 (an interesting choice of words?) on the International tab together with any "Name Input" choices could be helpful?

[davidf]

The primary purpose of this thread was to satisfy the OP request of handling Surname-Prefix (SPFX) and Surname imported from TMG. It seems that objective has been achieved. Everything else is an elaboration taking the discussion much further and I'm unclear what it hopes to achieve.

What are the end user requirements? They have been stated by the OP.

But ... Adrian reminds me (and the rest of us)

...
Which brings me to a concern I have with this thread. What are the end user requirements? Access to Surname-prefixes and all the rest of that isn't a requirement - it's a solution (which, in FH, may or may not satisify the requirements). If anyone feels their concerns are being dismissed by that statement, I apologise - but I have been burned by this confusion myself.

How do names need to be presented in reports and charts? - that's another important requirement.

Another potential requirement - Is it important that children default to a certain "family name" when created in FH? (Currently the offspring of John Doe and Mary Roe default to a family name of Doe - not helpful if patronymics are involved)

It's perfectly logical that requirements may be satisfied in other software by access to the prefix and suffix items, etc. It's also perfectly possible that some aspect of FH may sabotage charting, sorting and reporting because it uses prefix, suffix, etc, differently. But we might not realise that without understanding the requirements.

Again, I apologise if this sounds like a critical review, but I feel it's important to bring out what isn't necessarily clear.
...

Many years ago when trying to project manage the introduction of a Manufacturing Requirements Planning system, when I naively ask the users about requirements the answer I got was "it must look like our current system"

I'm still a TMG user but looking for a new program.
...
FH recognize the names in my project very well but can't handle the different parts. Specially in the Dutch language the handling of the separate surname prefix (SPFX) is important.
I...
If FH could incorporate the handling of the structured name tags, I buy the program and I'm sure with me many more TMG users. ...

To an extent that is what the OP is saying they want FH to be like TMG - which is jumping to a solution as Adrian, I think correctly, points out. Mike's plug-ins have sort of found a work-around to the OP's original "issue" - the cutting up of names into the parts that they were used to.

But ...

When they go on to add other family members through the FH single NAME field - or wish to update a name through the same field, are they going to be happy? They could run the plug-in after every edit (if they remember) and if the plug-in does the parsing exactly right they will be OK, but if they forget or the parsing meets a "new" surname prefix not anticipated, they could end up in a muddle.

What are the end user requirements?

I might guess it could start as something nebulous like "adequately handle a variety of non (English) standard name structures" (starting with Dutch/Flemish/German). As Adrian says there are a number of solutions to that other than the "requested solution".

I think that is a valid "wish list" request; whether CP choose to run with it is another matter.

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)?

[ColeValleyGirl]

The primary purpose of this thread was to satisfy the OP request of handling Surname-Prefix (SPFX) and Surname imported from TMG. It seems that objective has been achieved. The plugin was originally intended as a bespoke solution for the OP. Everything else is an elaboration taking the discussion much further and I'm unclear what it hopes to achieve.

Is it faintly possible that people might be enjoying the discussion? That what they hope to achieve is a better understanding of the subject, and possible approaches to it? Perhaps even generate a fully formed wish list request, somewhere where it hasn't lost the context that triggered it (so don't suggest splitting the topic).

What are the end user requirements? They have been stated by the OP.

The OP wants to continue working as close to the way they were accustomed to work as possible -- and as always, you have stepped in with a plugin to meet a specific need, so the OP is happy. But -- as Adrian and others have pointed out -- that's a very specific answer to a single user's request -- it isn't a user requirement specification that anyone with long experience in the IT industry would want to use for a more generic solution. And I -- and I also suspect others -- worry that you've just kicked the can down the road, without addressing: sorting, diagrams, reports, exporting, queries, the impacts on other plugins, the need to remember to run the plugin regularly or at specific triggers.... Is there a role for a customised 'names' tab in the property box? What about Name fields in source templates? (Some of these may fall magically out of what you have done, but it is far from clear that that is the case).