![]() The iFamily website states, “As GEDCOM export is disabled in our demo, hold it’s performance to the same standard as our GEDCOM import process.” Fortunately, iFamily uses GEDCOM tags for its Event Types, so I could at least surmise what tags it would use to export a GEDCOM. GEDCOM 5.5.1:As noted above, the iFamily Demo does not include GEDCOM export. This shortcoming also leads to the next problem. That’s probably why it imported my invalid event description into the Event Name field. But here’s the problem: iFamily doesn’t have a separate event description field it has only the Event Name field, so if there’s both a description and a name (which is really a type), it can import only one or the other. On its website, iFamily gives even worse advice on the Tutorials page under Tips it states, “Enter ‘Y’ for a birthdate or deathdate if you want it to be searchable during consistency checks.” If a date is unknown, you should not enter “Y” in the date field (or the place field) you should enter it in the event description. Fortunately, iFamily doesn’t squawk if you leave the date blank. If a date is unknown, it must be left blank (unless it can be estimated). Also notice in Fig 2 the statement, “An event must have a Date, a Type and a Name.” I agree an event must have a type, but a Name is required only for user-defined events like Arrival or Departure, and I strongly disagree that an event must have a date. The Event Name is the Event Type spelled out, such as “Birth” or “Death.” But where it should say “Birth,” it imported the invalid description instead, and there’s no way to change it. iFamily also violated this rule it imported invalid event descriptions into the Event Name (Fig 2). Many genealogy apps violate this rule, including Family Tree Maker (FTM), which enabled me to include it in my test GEDCOM file.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |