* Asian name order and "/"

[KFN]

Based on another issue, and not wanting to step on their thread, I went to look at a few individuals in a tree that I have and I see the same thing.

Wang Xiu.jpg (22.26 KiB) Viewed 779 times

The GEDCOM is accurately ordered for this individual:

Code: Select all

1 NAME /Wang/ Xiu Mai
2 GIVN Xiu Mai
2 SURN Wang

FH correctly identifies the Surname in

Wang Xiu 2.jpg (3.1 KiB) Viewed 779 times

Is this just an anomaly because FH does not support Asian names (surname first) very well? I had expected the "/" marks to be removed like they are in Western tradition names!

Thanks

[LornaCraig]

(I have moved this topic to the General Usage forum as it is not related to Importing or Exporting)

From the FH Help fies:

When viewing names in Name fields, for editing purposes, Family Historian can, if you wish, always put slashes round thesurname, to make it clear which part of the name is the surname. However, for aesthetic reasons, Family Historian by default keeps the use of slashes to a minimum, and only puts slashes round the surname when this is needed for clarity - that is, if the surname is not the last name,

The display is controlled by Tools>Preferences>Property Box, where the options are Display surnames Between Slashes: Only When Necessary (the default) or Always.

If you choose Only When Necessary, Family Historian will only mark the surname by slashes if the surname is not the last word in the name, or if the recorded name consists of one word only.
Whatever option is chosen here only affects Name fields in the Property Box. It has no effect on how names appear in reports, books, charts, diagrams, web-pages, or on how they appear elsewhere in the program. It also makes no difference to how you enter names into Name fields.

[tatewise]

That is why I set the option to Always so the surname is always displayed consistently between slashes.
It makes identifying and entering surnames that include spaces &/or have non-surnames before and after so much clearer.

[Mark1834]

The GIVN and SURN tags are actually superfluous, and FH neither uses nor needs them to correctly denote the surname. I suspect they are included simply to support the claim of GEDCOM compliance.

[KFN]

Thanks Mike, that makes a big difference!

[AdrianBruce]

The GIVN and SURN tags are actually superfluous, and FH neither uses nor needs them to correctly denote the surname. ...

Not merely does it not use them, it is possible for them to get out of step with the NAME - certainly I just tried setting up a name with a different SURN and it worked fine.

[KFN]

Adrian,

GEDCOM allows for the NAME tag and the SURN tag to be different. The v7.0.12 GEDCOM actually says that the value inside the "/" can be different than the SURN tag to:

in particular it is recommended that all name parts in PERSONAL_NAME_PIECES appear within the PersonalName payload in some form, possibly adjusted for gender-specific suffixes or the like. It is permitted for the payload to contain information not present in any name piece substructure.

An example would be that many Eastern European surnames are gender specific and the SURN value can be used to consolidate various names under one root surname. Example: Polish individuals add suffixes to a root surname; -SKI, -CKI and -DZKI (male), become -SKA, -CKA, -DZKA (feminine), the root surname could be "MALINOW" with the female surname MALINOWSKA and the male surname MALINOWSKI.

Also multiple SURN tags are also valid one for each family name in a Spanish, Portuguese name custom.

[AdrianBruce]

... GEDCOM allows for the NAME tag and the SURN tag to be different. ...

Oh.. Mind you, there's a difference between NAME and SURN being "different" and NAME and SURN being contradictory, which is what I ended up with many years ago in FH, because it doesn't / didn't use SURN etc.

... Example: Polish individuals add suffixes to a root surname; -SKI, -CKI and -DZKI (male), become -SKA, -CKA, -DZKA (feminine), the root surname could be "MALINOW" with the female surname MALINOWSKA and the male surname MALINOWSKI. ...

Interesting. I can see the virtue of such a representation. My tidy mind is rebelling about not having such variants properly labelled and / or explained. But how many variants would there need to be in labelling??

... Also multiple SURN tags are also valid one for each family name in a Spanish, Portuguese name custom.

I do worry there that without a lot more prompting (in the specification?), the software will ignore such niceties and the SURN tags will end up contradictory, not different. But again - how on earth does one cope with specifying the variation?

[KFN]

Adrian,

Unfortunately, not much has change going forward regarding the “required use” of the SURN tag in v7. Any receiving program can drop the tag on import, without prejudice!

I use this in my primary GEDCOM to manage individuals without surnames, but that are part of a family group, but this construct is only supported by the software I use.