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

Questions regarding use of any Version of Family Historian. Please ensure you have set your Version of Family Historian in your Profile. If your question fits in one of these subject-specific sub-forums, please ask it there.
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

Jean001 wrote: 21 Jun 2022 16:15 the FH user needs to be able to enter the name so that indexing is correctly applied to his/her desire.

Perhaps a 'Sort as' option might be useful. In my project, there are a number of names that are 'wrongly' sorted in the Records Window (e.g. Mc/Mac and O'...). I'd like to re-order those names. (In an index, Mc... is sorted as 'Mac' and the apostrophe in O'... names is ignored.)
That is an interesting way of expressing the requirement - it could go two ways
  1. An ability to enter the name an additional time in a manner that indicates how it should be indexed (defaulting to Smith, John; if blank): Karajan, Herbert von; du Pré, Jacqueline; OConnor, Patrick; Aubespine, Sebastien de l' (?). Or better?:
  2. Some form of template pull-down - defaulting to Smith, John, but with other examples such as the above - with a live response to how the actual name would be formatted (the template may need the slashes).
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

Try the attached Match Name with Components plugin Version 0.6 Date 21 Jun 2022.

This version saves the user dialogue settings in the global ProgramData for FH.
Thus the settings are the same as the previous use of the plugin for every Project.

It also checks the surname prefix case rather differently.
Previously it just checked whether the first character was any letter from a to z.
Now it checks the entire prefix is lower case and caters for all Unicode characters.
Last edited by tatewise on 02 Feb 2024 12:30, edited 1 time in total.
Reason: Attachment deleted as a better version is attached later.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

Thanks, that seems to do what I want - with the file that I have (I have not tried it on a fully spec'ed test file.

I also like the clearer distinguishing between Parsing and Assembling.

That is good for an import or bulk maintenance routine. I have been wondering about a one record (technically a one name at a time) subroutine to run on an event (add/delete/edit any of NAME GIVN SPFX SURN). It would have to initially be a plug-in to manually run when the user has done any of the events listed. (See my earlier post with a mocked up dialog)

It really is a pity that the API does not allow you to specify the event on which a plug-in is to run - there could be security implications that CP might not like, but I'm not so sure.

Alternatively on the customise tab dialog (and others?), to be able to add a button and attach a plug-in to its on-press event ...
Name Parse or Assemble pseudo code.txt
Pseudo Code for One Name Routine
(2.6 KiB) Downloaded 46 times
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

As I said earlier, after the plugin has been run to bulk adjust the names, the Names and pieces are all compatible.
So if only one Individual is changed, running the plugin will only update that one record.
There is not really any need for a separate one-record plugin.
But if it was necessary to just focus the plugin on one record then a setting could be added to the user dialogue.

You may find these two Wish List entries of interest:
Ref 547 Run Plugins via Expressions or via a button would be similar.
Ref 484 Either remove or maintain the GIVN and SURN Tags

I presume when you say "I also like the clearer distinguishing between Parsing and Assembling." that you are referring to the plugin script.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

The reason that I was pondering a more extensive dialogue which would load the present state of NAME and the parts GIVN, SPFX & SURN was that the user may wish to have some quick easy say in the parsing to parts or assembly of parts. This would enable us to get round the issue that the parsing rules will never be perfect.

Suppose you have a customised tab that permits editing of the 4 fields in question (or even a dialog which permits editing of just one of the fields). To expect the user to manually keep them aligned is prone to issues, Without main code modification the best we can do is a streamlined plug-in which can be run after every add/amend/delete to take a number of steps when run:
  • If the current record is not an Individual record, exit
  • If the parts are in line perhaps it could just give some signal and exit
  • If the parts are not in line you could (from user preferences about direction of alignment) just align them.
    • For traditional users you parse the NAME into the parts ;
    • for "international users" you assemble the NAME field from the parts
  • Alternatively you could bring up a dialog with the four relevant fields
    • Prompt the user to do one of
      • Manually edit to bring them into line
      • Parse the NAME into parts - using your parsing logic
      • Assemble the Name from the parts
    • Move on by
      • Saving and Exiting (possibly only if the parts are in alignment)
      • Saving and moving to the Next NAME[i+1] (if you are amending NAME[p] you probably want the option to amend NAME[q] as well
      • Saving and moving to the previous NAME[i-1]
      • Adding a new name through the same dialog
    • Possibly do something to record how you have decided on a non standard parse
  • Not have the result table query displayed as that inhibits what users may think of as part of their normal workflow
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

tatewise wrote: 21 Jun 2022 19:40 ...
You may find these two Wish List entries of interest:
Ref 547 Run Plugins via Expressions or via a button would be similar.
Ref 484 Either remove or maintain the GIVN and SURN Tags
...
Running Plug-ins via an expression would end up with something a bit like Excel & VBA Custom functions (although it is a while since I did one of them). I have pondered the benefits of being able to write custom functions - but we could do with a wider range of primitive functions to make full use of the feature. I am still trying to get my mind around how you plan to pass parameters - ideally it would be as like other functions as possible.

I'm not so sure about the other one; it's a bit blunt. The Standard anticipates two name structures NAME and GIVN+" /"+SPFX+ifexists(SPFX)," ", "")+SURN+"/" - I think it has to anticipate a way to keep them in line. I think this thread has shown that removing support for GIVN, SURN (and presumably SPFX) is over restrictive.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

Ref 547 Run Plugins via Expressions explains how parameters would be passed.
=CallPlugin(...) would have a first parameter naming the plugin, followed by any other parameters just like any other function.
The plugin would have an API mechanism to read and return parameter values.
That would be very similar to the entry point API used by Language and Report plugins as described in 'How to Write Plugins' sections for 'Special Plugin Types' for FH V7.

BTW: The GEDCOM Name pieces also involve NPFX and NSFX but not sure how they interact with the NAME field.
i.e. NAME = NPFX+if(NPFX)," ","")+GIVN+if(GIVN)," ","")+"/"SPFX+if(SPFX)," ","")+SURN+"/"+if(NSFX)," ","")+NSFX
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

tatewise wrote: 22 Jun 2022 09:25 =CallPlugin(...) would have a first parameter naming the plugin, followed by any other parameters just like any other function.
The plugin would have an API mechanism to read and return parameter values.
Ah, OK that makes a bit more sense.

Alternatively do we have a "function switch" in the definition of plug-ins, normal set to "off", but if set to "on" means the plug-in can operate as a function? (Possibly with an enforced naming convention so that custom functions are "obvious").

That would go in the plug-in header - possibly together with an array of fh events which can "fire" the plug-in" before/after or instead of the normal event. I suspect CP would feel that is letting us peer too deeply into their proprietary code! (But if open source ...)
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

David, your last two paragraphs are dealt with by my reference to Language and Report plugins as described in 'How to Write Plugins' sections for 'Special Plugin Types' for FH V7. They could be 'Function' plugins with 'entry points' for events.
The FH V7 'How to Write Plugins' page is not online and you only have FH V6.2 so you cannot see how they could apply.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

tatewise wrote: 22 Jun 2022 09:25 BTW: The GEDCOM Name pieces also involve NPFX and NSFX but not sure how they interact with the NAME field.
i.e. NAME = NPFX+if(NPFX)," ","")+GIVN+if(GIVN)," ","")+"/"SPFX+if(SPFX)," ","")+SURN+"/"+if(NSFX)," ","")+NSFX
Part of the Confusion arises from the differences between the NAME field in fh which is commonly understood to be "GIVN /(SPFX )SURN/" where the "Surname" is believed to be NAME:SURNAME which is parsed as /(SPFX )SURN/. However the contents of the NAME field are stored on the %INDI.NAME% line.

fh would get confused if a full built name such as you quote:
NPFX+GIVN+/+SPFX+SURN+/+NSFX was entered and stored on the %INDI.NAME% line!
(conditional spaces removed for clarity - is this NAME:FULL - I can't find documentation of the NAME:Qualifiers?)

In this (fh) context the NAME "dialog field" stands apart from NPFX and NSFX the Name Prefix and Suffix having an existence external to the NAME "dialog field". (See the dialog behind the Name: More ...)
Name: More ...
Name: More ...
Screenshot from 2022-06-22 13-33-14.png (17.87 KiB) Viewed 2187 times
The GEDCOM standard appears to give all name pieces equal standing when I think many of us (at least Anglospheric users) believe there is an implied but unenforced hierarchy with two implied entities (PSNM and FAMN below).
  • %INDI.NAME%
    • NPFX
    • PSNM (Personal Name - the FH NAME field - actually stored on %INDI.NAME%)
      • GIVN
      • / (optional - but required to parse SPFX and SURN)
      • FAMN (Family Name - the FH NAME:SURNAME - which requires the slashes)
        • SPFX (optional and if alone interpreted as SURN?)
        • SURN
      • / (optional - but required to parse SPFX and SURN)
    • NSFX
    • NICK
    • _USED
PSNM and FAMN being implied TAGS that none-the-less are entities recognised by FH.

NAME:QUALIFIER can be used to unambiguously derive FAMN provided we follow the convention that you enter only the Given Names and Surname (with surname prefix) in the NAME "dialog field"

NPFX and NSFX are not in the FH NAME - if they were, NAME:GIVEN_ALL would return NPFX and NSFX as Given Names.

This is a mess!
Last edited by davidf on 23 Jun 2022 07:56, edited 1 time in total.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

The Name Qualifiers are explained under Help > General Topics > Name Formats.
See https://www.family-historian.co.uk/help ... rmats.html
The qualifiers only operate on the contents of the INDI.NAME field. The subsidiary Name Pieces are not involved.

Just to avoid any doubt, FH does NOT perform any correlation or transfer of values between the Name field and any of the subsidiary Name Piece fields. It is only my recent plugin that performs such functions.
In most cases, the fields are inconsistent because the subsidiary Name Piece fields are often mostly empty.

The following data hold entirely independent values that may be and often are inconsistent with each other.
All this data is available in the All tab and a subset is in the Names & Titles dialogue.
The whole set repeats for Alternate Names but with index [2] or [3], etc.
INDI.NAME[1] is the Primary Name field
INDI.NAME[1].NPFX is the Name Prefix field (Prefix on All tab)
INDI.NAME[1].GIVN (Given on All tab)
INDI.NAME[1].SPFX (Surname Prefix on All tab)
INDI.NAME[1].SURN (Surname on All tab)
INDI.NAME[1].NSFX is the Name Suffix field (Suffix on All tab)
INDI.NAME[1].NICK is the Nickname field (Nickname on All tab)
INDI.NAME[1]._USED is the Given Name Used field (Given Name Used on All tab) ~ FH non-standard GEDCOM extension

So to say the NAME field in FH is commonly understood to be "GIVN /(SPFX )SURN/" is misleading because GIVN, SPFX & SURN are usually empty.

If a user wishes, they can replicate any of the subsidiary Name Piece fields in the Name field or compose the Name field disregarding the subsidiary Name Piece fields that may be empty.
So a NAME such as Dr. John James /van Gogh/ Snr is perfectly valid and allowed by FH.
It just means that some Qualifiers may return unconventional values that the user must live with.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

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

Post by Kaaskop »

tatewise wrote: 21 Jun 2022 17:31 Try the attached Match Name with Components plugin Version 0.6 Date 21 Jun 2022.

This version saves the user dialogue settings in the global ProgramData for FH.
Thus the settings are the same as the previous use of the plugin for every Project.

It also checks the surname prefix case rather differently.
Previously it just checked whether the first character was any letter from a to z.
Now it checks the entire prefix is lower case and caters for all Unicode characters.
This 0.6 version gives the next error:
Image
Attachments
Schermafbeelding 2022-06-28 110038.jpg
Schermafbeelding 2022-06-28 110038.jpg (27.6 KiB) Viewed 2149 times
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

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

Post by Kaaskop »

I replaced it with the 0.4 version, that works.
User avatar
tatewise
Megastar
Posts: 28333
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

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

Post by tatewise »

Sorry, forgot to check that C:\ProgramData\Calico Pie\Family Historian\Plugin Data\ folder exists :oops:

Download & install the Match Name with Components plugin Version 0.7 Date 28 Jun 2022 that fixes the fault.

This version also detects lowercase Surname Prefixes such as de' that are separated from Surname with an apostrophe (') while treating O'Connor as entirely Surname with no prefix because the O is uppercase.
Last edited by tatewise on 02 Feb 2024 12:35, edited 1 time in total.
Reason: Attachment replaced by link
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

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

Post by Kaaskop »

Thanks, v 0.7 works fine as far as I can see.
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

I have been pondering the original wish list and the wider range of issues that could give rise to other wish list items and I want to propose a wish list item just to address the original SPFX issue.

Can I have comments on the following:

Internationalisation and Name Structures

A number of wish list items may usefully be grouped under this title. They all either make it easier for users to enter and manage non Anglo-Saxon data relating to names or improve functionality relating to names.

Handling International Name Structures 1. "Prefixed Surnames" - Handling of GIVN, SPFX and SURN

Requirement: To be able to easily enter/edit/process surnames or other non-anglosphere name structures and personal identifiers ("names")
. Stage 1 involves the use of the GIVN, SPFX and SURN fields to handle prefixes found in many Western Surnames.

Required Features:
  1. Enabled by Choice: "Prefixed Surname Handling" should be an optional feature that can be enabled by the user at Project Level and brings into use the [GIVN, SPFX and SURN] group of fields which can be considered to operate in parallel to NAME.
  2. NAME field retains functional supremacy: The NAME field (currently the primary Name field in FH) should remain the main name field and always populated (if necessary algorithmically from GIVN, SPFX and SURN fields) so that current FH features dependent on NAME (e.g. Record Window first column, Name Select fields, NAME._USED & Name:GIVEN FH custom fields and formats, text schemes, reports etc.) continue to work and if "Prefixed Surname Handling" is subsequently switched off the user effectively reverts to the vanilla state.
  3. User Configured: On enabling "Prefixed Surname Handling" the user to be giving a choice for entering and editing of names:
    1. e.g. "English Style" [Vincent /Van Gogh/] - "FH Vanilla Style"?
      • Continue to enter name information directly into the NAME field (as at present) and
      • for new names have the GIVN, SPFX and SURN fields algorithmically aligned with what is entered in NAME
      • with secondary access* to the GIVN, SPFX and SURN fields to check or amend the algorithmically derived data.
    2. e.g. "Dutch Style" [Vincent] [Van] [Gogh] - "FH Raspberry Ripple style" - a change threaded through?
      • Enter name information via existing dialogs which have replaced the NAME field with the [GIVN, SPFX and SURN] group of fields and
      • for new names have the NAME field aligned by concatenating the [GIVN, SPFX and SURN] group of fields (surname last)
      • with secondary access* to the NAME field to check or amend the data derived by concatenation.
  4. Name Edit - Visual clue about non alignment and an option to accept or edit derived values or to decline them:
    • Users need to be able to over-ride any attempts to programmatically align the NAME field with the GIVN, SPFX and SURN group and for any over-rides not to be over-written if either the NAME field or one or more of the GIVN, SPFX and SURN group are subsequently amended.
    • If the NAME field and the GIVN, SPFX and SURN group are out of alignment after any edit
      • the user needs a visual clue to that fact and
      • the ability to access* the secondary field or fields.
  5. Bulk Update and Review: Users need a bulk update routine available to ensure that both NAME and the GIVN, SPFX and SURN group are populated.
    1. when :
      • an existing project has "Prefixed Surname Handling" first enabled or re-enabled, or
      • importing a GEDCOM when "Prefixed Surname Handling" is enabled. This could be part of the import routine itself or a separate post-import routine. How this is done depends on the contents of the file to be imported, or
      • on user request as a Data Validation exercise.
    2. the routine needs to offer as output:
      • A list of instances where the NAME field was blank and entries are suggested based on the concatenation of the GIVN, SPFX and SURN group of fields
      • A list of instances where the GIVN, SPFX and SURN group were blank and entries are suggested based on algorithmically deriving possible entries from the NAME field
      • A list of items not in the above where the NAME and the GIVN, SPFX and SURN group are out of alignment.
    3. the user needs to be able on a line by line (or on a totality basis) to accept, amend or reject suggestions in the first two of the above groups and to choose what to amend in the last group.
Notes (Thoughts not necessarily to be carried through to the final wish-list):
User configuration
  1. Edit: Style Names need a permanent name (see Adrian's comment below) - "Dutch Style" is used because that was the issue for the original OP - although it has wider applicability.
  2. Do we also need a "Dutch Style" but with surname first in the Name field [/Van Gogh/ Vincent]. Are there examples that need this "style" - or do we just highlight that a later wish-list might be to create "another style"?
  3. For "Dutch Style" the dialog amendments in the Property Box for Adding a Name, Adding a Spouse are fairly straight forward. The Names and Titles dialog (and associated add Name Details dialog) would also need similar amendment. For Adding a Child it could be a bit crowded unless the width of the property box is slightly increased and the field contents allowed to horizontally scroll.
  4. * Secondary Access to the "other field or fields" might be by means of a small icon on the right of the NAME field of the Grouped GIVN, SPFX and SURN fields similar to the existing icon to open options on the Date, Place and Address fields in the Property Box - this would open a dialog showing the secondary fields populated with the data derived by algorithm or concatenation from the Primary field. This would use a concept already familiar to users.
  5. (An alternative to amending dialogs is to introduce an extension of the "slash convention" used for surnames (for instance delineate the Surname Prefix with a character such as | - or one that is on most keyboards but is highly unlikely to appear in a name. Then you could enter in the NAME field [Vincent /|Van|Gogh/] and FH would on exiting the field use the delineators to populate the GIVN, SPFX and SURN group before writing to the NAME field - after ditching the | . When loading a NAME field into a dialog FH would, by reference to the GIVN, SPFX and SURN group, reintroduce the | to enable editing. If this was done it would not be possible to have NAME and the GIVN, SPFX and SURN group out of alignment which could give problems in instances where the Surname Prefix and the Surname are not to be separated by a space. The differences between [Vincent /|Van|Gogh/], [Vincent /|Van |Gogh/] and [Vincent /|Van| Gogh/] then become significant and problematic.)
Edit
  1. When editing a name, it is probably undesirable to have the associated "secondary" field or fields algorithmically amended as the user may be deliberately keeping them slightly out of alignment - either because the algorithm did not give the "correct" result or for instance to enable the NAME field to be used for "as displayed" and the GIVN, SPFX and SURN group used slightly differently to fine tune sorting.
  2. However because the dialogs are unlikely to show both NAME and the GIVN, SPFX and SURN group simultaneously a visual prompt is required to alert the user that the associated "secondary" field or fields may also need editing. Possibly the background colour of the field might change colour or the icon to access the secondary fields might change in some way?
I don't think it is appropriate to go into deeper detail - we would then be in danger of specifying solutions rather than requirements (per Adrian's warning) - but I felt some detail was required in a wish list item as potentially complex as this so that readers can feel that it is possible to see their way to a solution that is reasonably easy and familiar and does not add unnecessary complexity to their work flow.
Last edited by davidf on 06 Jul 2022 08:28, edited 2 times in total.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

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

Post by AdrianBruce »

David - I'm slightly worried about the presentation of your ideas, in that you talk about "Internationalisation" and yet appear to major on the Dutch aspect. Am I reading too much into this?

In any case, I will throw in a link that I saved some time ago about Spanish family names: http://yuba.stanford.edu/~molinero/html/surname.html This is just for information but it does appear to me that it will be important if it's ever desired to predict the name of a "Spanish" child from the names of the parents. That ability exists now for purely "English" format names in that it will carry down the father's family name as a default for any child - unless you switch it off. Clearly such a carry down to generate a default in Spanish names would require the isolation of the different parts of the family name.
Adrian
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

AdrianBruce wrote: 05 Jul 2022 16:03 I'm slightly worried about the presentation of your ideas, in that you talk about "Internationalisation" and yet appear to major on the Dutch aspect. Am I reading too much into this?
Yes! I referred to "English Style" and "Dutch Style" purely because the OP was talking about Dutch examples - the inverted commas were intended to indicate that they were pro-tem labels - open to suggestions!
AdrianBruce wrote: 05 Jul 2022 16:03 In any case, I will throw in a link that I saved some time ago about Spanish family names: http://yuba.stanford.edu/~molinero/html/surname.html This is just for information but it does appear to me that it will be important if it's ever desired to predict the name of a "Spanish" child from the names of the parents. That ability exists now for purely "English" format names in that it will carry down the father's family name as a default for any child - unless you switch it off. Clearly such a carry down to generate a default in Spanish names would require the isolation of the different parts of the family name.
That is an area I have been wondering about! I have on the tabs next to this tab
https://en.wikipedia.org/wiki/Spanish_naming_customs (Often - how often?: Father's 1st surname and Mother's 1st Surname) and
https://en.wikipedia.org/wiki/Portuguese_name (looks more varied)
I have also been looking at Russian (possibly Slavic) Surnames which depend on gender (e.g. Tchaikovsky (m) / Tchaikovskaya (f) )

If FH wants to appear International it needs to be less Anglo-centric and I would not want the current ability to handle Patrilineal surnames removed, so it means thinking about what can be realistically done as options. Family trees are spreading and are no longer as mono-cultural as they used to be!

Possible options - in no particular order at the moment.
  1. Options extended from current None or Patrilineal to include Matrilineal (rare but logically easy to program!)
  2. If only one parent is known, child to take that parent's surname by default (handle "English illegitimacy")
  3. "Inherit to descendents" If I have a child Simon Jones and I add a father, can't we default the father's surname (if option is set to Patrilineal)?
  4. Options to be set at family level and then inherited down. So if someone from a Patrilineal society marries into a society which has a different convention, to be able to set the default (from current options) to None and for that to apply to all descendents until changed.
  5. Where on marriage a couple change their name - the Name Type in V7 can indicate that this is a matrimonial name; an option to ensure this is used for the children? Could handle English and American double barrelling and some non English patterns - but need to ensure you pick up the Married Name that matches the couple! A custom fact on the FAM record?
  6. If the variety of endings are not too large, an ability to handle the Tchaikovsky (m) / Tchaikovskaya (f) tyep example.
I think I possibly branch this topic to discuss this issue?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

davidf wrote: 05 Jul 2022 17:59 I think I possibly branch this topic to discuss this issue?
I have now branched discussion of default surnames when adding children to a separate topic
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

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

Post by davidf »

Just trying to prove to myself that changes to handle GIVN SPFX & SURN will not be too obtrusive:

Enabling "Prefixed Surname Handling" will require a choice of how to handle name entry

1. Much as before - near "Vanilla" if you like
Enabled but with Vanilla Entry
Enabled but with Vanilla Entry
Vanilla.png (28.13 KiB) Viewed 1955 times
The only change is the small icon visible at the end of the Name lines - which gives access to a dialogue (not shown) with the algorithmically determined name parts GIVN, SPFX and SURN - available for editing.

2. With direct entry of the Name Parts - "Raspberry Ripple"* if you like
Enabled but with Direct Part Name Entry
Enabled but with Direct Part Name Entry
Raspberry.png (29.9 KiB) Viewed 1940 times
Cosmetically the NAME field has been replaced with the three Name Part Fields - following the visual convention for the Add Child line with narrow dividers between the fields and a heading line - with the small icon visible at the end of the Name lines - which gives access to a dialogue (not shown) with the NAME field value determined by concatenating the three Name Part Fields - available for editing.

The Surname Prefix field may have to Horizontally scroll to handle long or multiple prefixes such as "von und zu".

Similar treatments would apply to the few other Name entry or edit dialogs.

(The above are based on my V6 dialogs with some customisations in place)

* I'm not sure if "Raspberry Ripple" is recognised IT slang, but I certainly met the expression when doing an MRP system implementation. The recommendation was to "go vanilla" and use it as it came "out of the box" as maintenance and support would be so much easier. But users insisted on customisations - moving away from vanilla to what we termed "Raspberry Ripple" - little threads of local flavour running through it. The IT manager responded "you do realise, it's not raspberry, but the blood and sweat of my team?".
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

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

Post by AdrianBruce »

davidf wrote: 06 Jul 2022 09:34... users insisted on customisations - moving away from vanilla to what we termed "Raspberry Ripple" - little threads of local flavour running through it. The IT manager responded "you do realise, it's not raspberry, but the blood and sweat of my team?".
Like it! I'd never heard that - but then again, I lived in a bespoke coding environment.
Adrian
avatar
jelv
Megastar
Posts: 565
Joined: 03 Feb 2020 22:57
Family Historian: V7
Location: Mere, Wiltshire

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

Post by jelv »

How does this suggestion work for names like Ding Junhui where Ding is the family name and Junhui is his given name? If it's internationalised it should work for Chinese names!

At the moment the name would be entered as /Ding/ Junhui
John Elvin
Post Reply