[Proposal] Replace 2 _MARNM with 1 NAME/2 TYPE married, etc.

[fisharebest]

We support subordinate names using FamilyTreeMaker-style _MARNM and _AKA tags. e.g.

1 NAME Jane /Black/
2 _MARNM Jane /White/
2 _AKA Sister Mary

Presumably FTM has (had?) a limitation of one NAME record per individual

These are not GEDCOM standard, and are liable to be ignored by other applications. A valid GEDCOM structure would be

1 NAME Jane /Black/
1 NAME Jane /White/
2 TYPE married
1 NAME Sister Mary
2 TYPE aka

I propose that we stop supporting these FTM-style names (edit, display, etc.) and instead automatically convert them into valid GEDCOM.

We could apply this conversion in the "import/save gedcom" logic, where it would be applied to both GEDCOM import and edit/save operations.

[DJAlik]

Can we also incorporate adding names in different alphabets?

Something similar to:

1 NAME Alexander /Rusinov/ 2 TYPE Latin 1 NAME Александер /Русинов/ 2 TYPE Cyrillic 1 NAME /אלכסנדר /רוסינוב 2 TYPE Hebrew

On Mon, Jan 4, 2016 at 3:18 PM, Greg Roach notifications@github.com wrote:

We support subordinate names using FamilyTreeMaker-style _MARNM and _AKA tags. e.g.

1 NAME Jane /Black/ 2 _MARNM Jane /White/ 2 _AKA Sister Mary

Presumably FTM has (had?) a limitation of one NAME record per individual

These are not GEDCOM standard, and are liable to be ignored by other applications. A valid GEDCOM structure would be

1 NAME Jane /Black/ 1 NAME Jane /White/ 2 TYPE married 2 NAME Sister Mary 2 TYPE aka

I propose that we stop supporting these FTM-style names (edit, display, etc.) and instead automatically convert them into valid GEDCOM.

We could apply this conversion in the "import/save gedcom" logic, where it would be applied to both GEDCOM import and edit/save operations.

— Reply to this email directly or view it on GitHub https://github.com/fisharebest/webtrees/issues/794.

http://www.facebook.com/djalik http://twitter.com/#!/DJAlik http://www.linkedin.com/in/alexrusinov http://plus.google.com/114580313768137070684 http://www.mixcloud.com/djalik/ http://psnprofiles.com/DJAlik

[fisharebest]

We already have alphabet detection. If you view the page in a cyrillic language (e.g. Russian), webtrees will show the cyrillic name. If you view the page in a latin langauge, webtrees will show the latin name, etc.

2 TYPE Latin provides no aditional information, since we already know the name is written in Latin. It also allows users to enter conflicting information. e.g. what would we do with

1 NAME Alexander /Rusinov/
2 TYPE Cyrillic

[DJAlik]

I was thinking more from the form perspective. Instead of putting in alternatives into "also known as" have another drop down next to that field and select the language/alphabet.

[fisharebest]

Instead of putting in alternatives into "also known as"

If these are just the same name in different languages, then they are not "aka" names. They are (all) the primary/birth name. Just add them.

1 NAME Alexander /Rusinov/
1 NAME Александер /Русинов/
1 NAME /אלכסנדר /רוסינוב

[vytux-com]

I have been dreaming of this feature for a few years now.

[Amgine0]

Took a quick spin around some other genealogical data standards, and all support multiple married names (gedcomx, familyshowx, gramps xml, etc.)

[fisharebest]

What do you mean by

all support multiple married names

Do you mean that they use

• 1 NAME / 2 _MARNM
• 1 NAME / 2 TYPE married
• both of these

[ddrury]

Good idea. Any other non-standard tags that could get the same treatment?

[fisharebest]

Any other non-standard tags that could get the same treatment?

If you think of one, can you create a separate issue for it...

[Amgine0]

GEDCOM is not the only formatting style.

• <name type="Married Name">
  • Gramps XML
• 1 NAME / 2 MarriedName (this is actually way off, but... https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#examples-2)
  • GedcomX
• <MarriedName>
  • Familyshowx

A couple of the softwares might allow only one married name at a time, previous married names becoming "Also Known As" or "Other Name", at least if I understood the bug report correctly.

[ddrury]

If you think of one, can you create a separate issue for it...

Unfortunately I'm not sufficiently familiar with the Gedcom standard and it's variations

[ddrury]

Just had a play with this and it affects the way the names are displayed within the name accordion of the individual page (see attached)

Personally I prefer the _MARNM way of displaying the names

[Amgine0]

Whereas I prefer the latter, as it clearly separates the citations/evidence, media, notes, etc. for a separate name from that of the birth name.

[wooc]

I preffer this way of recording married names. On my site I'd use it for several years.

[ddrury]

Looks like I bow to the majority

[NorwegianSardines]

I've never been a fan of the _MARNM or _AKA in any way. I would propose that we implement this and instruct admin how to convert any instances of this tag to a proper GEDCOM syntax.

The TYPE should be "married" and "aka" for consistency, but others may like something else.

[fisharebest]

We should review this for the 2.0.0 release

[NorwegianSardines]

I am totally in favor of converting _MARNM and _AKA tags to valid GEDCOM at load time. I would guess that the upgrade process would automatically convert all custom tags of this type to valid GEDCOM as well.

[melizaa]

On my site, we need to ensure that the old 1 NAME and the 2 _HEB name will be the 1st names, so that these names will be shown on the site.

[WGroleau]

I prefer standard GEDCOM for many reasons, but as a concession, I vote for the standard being the default but the current behavior available as an admin selection.

I also note that in the current behavior, if the married name field is left blank, automatically creates a _MARNM for a female with the main name, but does not do so for a male. These cultural assumptions—that women change their names at marriage, and that men don't—are no longer valid even for English-speaking culture, and have never been valid for many cultures. So that's another reason for shifting to standard.

[fisharebest]

The latest code creates TYPE married instead of _MARNM for new data.

We also have a "data fix" to convert existing data.