* Patronymics (& Matronymics/metronymics)

[BillH]

I think a wish list item would be good. I've never submitted one as I fear that it would get so few votes that CP might be unlikely to implement it.

Bill

[davidf]

I think a wish list item would be good. I've never submitted one as I fear that it would get so few votes that CP might be unlikely to implement it.

Bill

I think if it is required by a few it should be discussed as a Wish List Request (which is just another sub-forum). Then if it is feasible, I personally think it should become a formal Wish List Item.

I don't think our votes will necessarily decide what CP does/does not implement. We may get few votes for something that assists a few users with Patronymics etc. But if CP are thinking about how to widen their market appeal it might strike cord with them and they can then implement it taking into account any comments made (both against the wish list item and hopefully against the discussions giving rise to it).

We have an interest in the continued existence of FH and that probably means new users as much as up-graders. As I have remarked elsewhere, the English Speaking market may be nearing saturation, so growth may well be in Non-English Speaking Markets - which have different Name Patterns etc.

This sort of request as well as offering functionality to Anglo-centric users (e.g. Compound Names) offers something to prospective non-Anglo users - if not the full handling of non "Given /Surname/" pattern names. So subject possibly to not diverting development attention from other matters, these sort of ideas - if feasible and being supported by even a few non-Anglo users, should be supported by us.

[BEJ]

Thank you to all who have posted in this thread. It is helpful as I consider how to enter my Swedish ancestors. What sticks with me is @davidf’s idea: consider what you are trying to achieve with the name fields rather than their labels in FH/GEDCOM.

Which is why I was trying to get my head around not the labels we apply to fields (or field elements) but functionally "what they do". So in the FH implementation what is between the slashes is the "Primary Sort", the rest (before and after) is the "Secondary Sort".

P.S. In addition to compound and patronymic naming, in Sweden it was common for individuals to change their “surname,” such as when being accepted to a craft guild, joining the military, becoming a member of the clergy, moving to a new farm, or being admitted to nobility, among others. With passage of the Names Adoption Act of 1901, many Swedes decided to “freeze” their primary patronyms or geonyms as surnames. Into the 20th century, however, individuals pretty much used any surname they chose.

[Gowermick]

. Into the 20th century, however, individuals pretty much used any surname they chose.

Must make for ‘interesting’ genealogy research! And I thought old Welsh names were dificult

[davidf]

I have now posted a Wish List Request for the below (slightly evolved):
Name Filtering to handle inconsistent entry or miss slashing of names (21168)

Are we getting to a stage where a Wish List Request is beginning to become relevant (and be exposed to people who are not interested in Patronymics etc.)?

The Requirement might be something general along the lines of:

Name Filtering

The Name Filter Function in the Records Window and Selection dialogues should be able to handle situations where Names have been miss-slashed or inconsistently slashed (e.g. Compound Surnames, Patronymics and Toponymics).

This would make it easier to filter and select names (particularly non Anglo-Saxon "Given /Surname/" patterns) as well as catching accidental duplicates due to inconsistent input.

Notes:

1. A user switchable (but persistent) option to swap between the current Last Name and First Name input boxes and an Anywhere input box (where "Anywhere" could include all Name Parts - suffix, prefix, surname prefix, nickname, used etc.) might achieve this.
2. At the same time adding the functionality to handle part matches other than the current "begins with" - either by "contains" or "begins/ends with" or full implementation of wildcards - would enable matching irrespective of "Mc" or "Mac" and similar.
3. If Soundex could be incorporated into the filter it would allow searching on name variations/miss-spellings (Taylor Tailor, Tailer) and avoid searching on created columns using the Soundex function.