You will only see this page if you opted to import a TMG file into your new project.
Note on TMG versions: Creation of fact definitions equivalent to tag type definitions, can only be done if you have TMG 8.05 or later. You can import earlier versions of TMG, but the creation of equivalent fact definitions will not occur in that case (see Creating Fact Definitions During Import below for more on this). For best results, we recommend users of earlier versions of TMG, to upgrade to version 9 if possible, before doing the import. If you are not sure how to do that, seek advice from other TMG users. For example, if you ask for advice on the Family Historian User Group (www.fhug.org.uk), there are ex-TMG users there who may be able to help you.
In most cases you can leave all options as the default values, unless you have specific problems you need to address. An exception is 'Languages'. You are advised to check this carefully and make sure you choose the most appropriate setting. If unsure, repeat the import multiple times and experiment with different settings.
Bear in mind that you can repeat the import as many times as you like. Every time you do an import, a new Family Historian project will be created. These can easily be renamed or deleted if required. Do not be afraid to experiment. Try an import, and look carefully at the results. For advice on locating imported items after import, and for pre- and post-import tips, see the article Importing from The Master Genealogist on the Family Historian website.
| Languages |
This is the language you wish to use when importing 'local sentences' and 'default sentences' from TMG. If the language you want is listed, you can select it from the list. If the language you want is not listed, you can just type it in. Take care when choosing the language value. You are recommend to double-check which language setting you are using. There are normally at least 3 possible variants of English, for example: "English (U.S.)", "English (U.K.)" and "English 2". If you choose the option "All English (U.K. preferred)", Family Historian will use values (for example, role names) defined in "English (U.K.)" for preference. But where no value is found, it will then try "English (U.S.)", and, failing that, "English 2". The option "All English (U.S. preferred)" is similar, but the order of preference is "English (U.S.)", "English 2", and finally "English (U.K.)". If you choose any other language, Family Historian will import sentences in that language if available. If there is no sentence in the chosen language, Family Historian will import an English sentence if there is one. If you choose the option, "(no language)", and if you are importing Event/Witness local sentences or tag type default sentences, all language versions for each sentence, will be imported together with the language codes. This is unlikely to be what you want for most purposes. |
|---|---|
| Add Fact Definitions To |
The possible values are:
See section Creating Fact Definitions During Import below. for an explanation of these options. |
| Enable Fact Definition Merging |
During import Family Historian has to match TMG tag types to Family Historian fact types. If necessary, Family Historian can create custom fact types for unrecognised tag types; but it will try to match standard TMG tag types with standard Family Historian fact types where possible. Each TMG tag type can be associated with a GEDCOM tag for export (this is done on the Tag Type Definition window within TMG, accessible in version 9 from the Master Tag Type List). All standard GEDCOM tags are supported within Family Historian; so for every standard (event/attribute) GEDCOM tag used within TMG, there should be an equivalent fact type that Family Historian can match this too. Within TMG, it is possible to associate the same standard (event/attribute) GEDCOM tag with more than one tag type. If this happens, Family Historian will match the first tag type that it encounters that uses this GEDCOM tag with a standard Family Historian fact type. If fact definition merging is not enabled, it will create a custom fact type for 2nd and subsequent tag types that it encounters, that use the same GEDCOM tag. If fact definition merging is enabled, it will match all tag types that use this GEDCOM tag with the same Family Historian fact type - i.e. effectively it will merge them on import. Unless you have taken the "Don't create/update fact definitions" option above, Family Historian will normally create a fact definition for each used fact type within a fact set called "TMG Import" (see previous). Only one fact definition will be created for each fact type used, based on the original tag type. This means creating the roles and equivalent sentence structures etc. If a fact type is effectively being matched to more than one tag type, Family Historian will base its fact definition on the first matching tag type that it encounters. For this reason, it is not recommended to enable fact definition merging unless the tag types that share the same GEDCOM tag, are all identical (i.e. have the same roles and same sentence structures etc). Conversely, if fact definition matching is not enabled, it is a good idea if possible to ensure, before doing the import, that different tag types within TMG do not share the same GEDCOM tag. The reason is that if two different tag types do share the same GEDCOM tag, one of them will be matched to a standard fact type within Family Historian and one will get a custom fact type - and it will be a matter of chance which will be the standard one. This can be important. For example, suppose you had two tag types that both had the birth GEDCOM tag ('BIRT'), and one of them was the real birth tag type, and the other was a rarely-used alternative birth tag type. In that case, it would be important to ensure that the first one was the one that Family Historian treated as the real birth fact type (because Family Historian uses birth facts - facts that it recognises as birth facts - for many things, including calculating life dates, ages, and much more). The only way of ensuring that the desired matching happens the way you want, is to ensure that only the first birth tag type has the 'BIRT' GEDCOM tag - and to arrange this before you start the import. Not all tag types in TMG have a GEDCOM tag at all. It is an optional field. If a tag type does not have a GEDCOM tag, or if the GEDCOM tag it has is not a valid standard GEDCOM tag for an event or attribute, Family Historian will ignore the GEDCOM tag, and create a custom fact type to represent the tag type, based on the fact name. |
| Attribute Text Values |
The possible values are:
|
| Attribute Notes | The possible values are:
Suppose you choose 'First sentence of memo' as the Attribute Text Values option, and suppose you choose 'Memo (unless duplicates value)' as the Attribute Notes option. If you have a memo which consists of 2 sentences, the first sentence only will be copied into the value field and the entire memo (both sentences) will be copied into the Notes field. If, however, you have a memo which consists of one sentence only, the same options will mean that the sentence (i.e. the entire memo) is copied into the value field. But the Notes field will be left blank (because if the Memo were copied into it, it would exactly duplicate the Value field). |
| Use Commas to Demarcate Place Parts |
Some versions of TMG allow you to specify up to 10 place parts separately. For example, the country name, if specified, is the 6th place part, using the standard TMG place style. Users who want to be systematic in the way they organise place parts, can do this in Family Historian too, by simply using commas to separate place parts - including missing place parts. So, for example, if you want to follow the standard TMG way of handling a US county and state, they are entered as place parts 4 and 5. To achieve the same thing, in Family Historian, assuming you just want to enter county and state and no other place details, you would enter them with 3 leading spaces (for the first 3 place parts which are missing) like this: ",,, Enon Valley, Lawrence County". If you wanted to enter the county (4) and country (6), but not the state (5), you would enter it like this: ",,, Enon Valley,, USA" The extra commas are removed when places are displayed in reports. The advantage of doing this is that all states, counties, countries, etc, will be grouped together in the main Place List, so you can easily sort on them and search for places on the basis of the part they belong to. You can also list them in separate columns in queries if you want to (you have to use the 'TextPart' function to do this - see "Understanding Functions" for more details). One way to access the main Place List is to click on "Work with Data" on the Tools menu, and then choose 'Places'. By default, this list only shows the first 3 place parts in separate columns. To make it show all 10 in separate columns click the 'Columns' button on the right-hand side, and specify '10'. The Use Commas to Demarcate Place Parts option, if enabled, does two things: it ensures that missing place parts are demarcated with commas as described above (if a place part itself contains commas, these will be replaced with semi-colons). Also, it enables the replacement of TMG codes that reference place parts, with Family Historian equivalents. Note: This option has no effect if the TMG version you are importing is an old one which does not support place part demarcation. |
| Import Relationship Notes & Citations |
TMG has a special class of relationship fact that is used whenever one person is linked as the parent or child of another. These relationship facts are used not only for birth parents, but also for adoptive parents, step parents, foster parents and god parents. It is possible to attach a memo to any such fact, as well as source citations. Family Historian handles these kinds of relationships a little differently. When you specify that one person is the parent of another, you do not always have to create a fact that will be listed in the Facts tab of the Property Box, to represent this relationship. However, if you wish to attach a memo (called a 'note' in Family Historian) to the relationship, or if you wish to provide source citations for it, or both, you may in that case need to create such a fact to represent it, if there isn't one already. Suppose, for example, that you want to add a source citation for the fact that X is the biological father of Y, you do this by creating a Birth fact for Y, and adding X as a witness to this fact with role of "Father". You can then add a note and/or source citations to X's role as father. Where a person has a role of this kind, there is normally no additional sentence required for this person in narrative reports (because these sentences will be generated automatically anyway). So the sentence template for roles of this kind are normally marked with a special code ("{blank}") which ensures that they do not get a sentence generated for them in narrative reports. Tick this option if you want Family Historian to generate facts and roles as-needed, to allow relationship memos and source citations to be imported. Tip: If you want to add a person as a witness to a given fact, with a specified role, you do this in the Witnesses Window. See that link for instructions on how to add notes and source citations for witnesses. Tip: Source citations and notes for spousal relationships are normally simply attached to marriage facts. |
| Convert TMG Sentence Codes |
Your are normally recommended to leave this option ticked (the default). TMG Sentence Codes are expressions like "[P]" or "[PO]" or "<in [L]>". They are used in sentence templates in tag type definitions. The sentence templates determine how facts are rendered as sentences in narrative reports. TMG Sentence Codes are also frequently used in 'local sentences' (called "sentence overrides" in Family Historian). For example, the equivalent of TMG's "[P]" code, in context, might be "{individual}" in Family Historian. See Importing Event/Witness Sentences below for more on this. |
| Log Code Conversions |
Tick this option to enable logging of conversions. See description at the top of this page for how to find the log file after import. |
| Code Replacements / Reset |
Code replacements are used when the codes in TMG's local sentences and default sentences are converted to the equivalent Family Historian codes (see Importing Event/Witness Sentences and Creating Fact Definitions During Import below). The code replacement process can be configured if you wish. This is an advanced feature for technically-minded users. If you wish to consider doing this, click and read the instructions in the file carefully before proceeding. If you make changes and later wish to revert to installation settings, click . |
Both TMG and Family Historian support narrative reports - that is, reports which read like a story. To achieve this, both programs define sentence templates (called 'default sentences' in TMG) for each type of fact ('tag type' in TMG). So, for example, there is a sentence template for 'birth' and another for 'death'. These sentence templates are used to generate sentences for each person whose birth and death have been recorded. The sentence templates contain special codes that are substituted with real data, when the reports are created. Both programs also allow you, the user, to modify the sentence templates if you wish to, and to define custom fact types, with their own sentence templates, if you wish to do that. Both programs also allow you to override and to modify the sentences, in particular instances (e.g. to modify the sentence that describes a particular person's birth or death, say). When you modify a sentence in a particular instance, you can if you wish (you don't have to) use codes in the modified sentence. The modified sentences are called 'local sentences' in TMG and 'sentence overrides' in Family Historian.
When you import a TMG project, any local sentences (sentence overrides) that you have in the project are also imported. Typically the local sentences will contain TMG codes that have no meaning within the context of Family Historian. The TMG codes are quite different from the Family Historian codes. The best solution is to replace the TMG codes with the equivalent Family Historian codes or expressions. This is called 'code conversion'.
Advanced users who wish to do so, can even override aspects of, and customize, the code replacement process. To do so, click the button and carefully read the advice and instruction in the file that is displayed. Remember that this is very much an advanced feature. Changes to this file could prevent code replacements from working at all. However, if you make changes and later wish to undo them, just click the button next to the button, to reset them back to their installation defaults.
Creating fact definitions during import requires access to TMG tag type details, and is only possible if you have a recent version of TMG. See the note at the top of this page for more details.
Even if you never modify any sentences, both TMG and Family Historian will still produce narrative reports. They do because each fact type (called a 'tag type' in TMG) is associated with a sentence template (called a 'default sentence' in TMG) which is used to generate an appropriate sentence in narrative reports.
About Fact Sets: Family Historian allows you to produce multiple sets of fact definitions, called 'fact sets'. The same fact can be defined in more than one fact set. All fact sets are ordered. For any given fact type, Family Historian will always use the highest ranked fact definition that it can find. Suppose you have a fact definition called My Fact Set which has a fact definition for birth, and you also have the Standard fact set which also has a fact definition for birth. You control the ordering of these fact sets. So let us suppose that you order My Fact Set ahead of Standard, giving it a higher priority. In that case, it will be the My Fact Set fact definition that is used for birth, and not the Standard one. In this case, the Standard fact definition for birth is said to be eclipsed by the My Fact Set one. If you now switch the ordering of the fact sets, it will then be the Standard fact set definition for birth that is used, and the My Fact Set one that is eclipsed. If, however, My Fact Set has a definition for hobby, and there is no definition for hobby in the Standard fact set, the My Fact Set definition will be used. An additional complication is that Family Historian fact sets can be system-level (meaning that they are available for all projects) or project-level (meaning that they are only available for a specific project. Project-level fact sets are always ordered ahead of all system-level fact sets.
Every imported fact has an associated tag type within TMG, and ideally should have an equivalent fact definition within Family Historian. Where possible and unless you tell it not to, for every TMG tag type that it encounters, Family Historian will create a fact definition (the equivalent of the TMG tag type definition) in a Family Historian fact set called 'TMG Import'. If you choose the option to make this project-level (see the New/Updated Fact Definitions option above), the fact set will be created new within the new project, and will be associated with that new project only. In that case, importing a TMG database into Family Historian has no effect on other projects on your PC. Project-level fact sets can later be converted into system-level fact sets, if you wish to do that. If you prefer, you can specify that the fact set should be a system-level fact set (still called 'TMG Import' though, to ensure that is easily distinguished from any other fact sets you may have). Keeping the fact set system-level can be a better option if you plan to repeat the import more than once. That way, if you make any changes to the fact set after import, these changes will still be there when you later repeat the import - so you won't need to do them again. Family Historian will only add fact definitions to the system-level 'TMG Import' fact set, if they aren't already there.
What happens if fact definitions are not created - either because you opted not to create them or because this option is not supported for your version of TMG? In that case, Family Historian will provide its own fact definitions for most facts. These will be similar but rarely identical to the TMG ones. Your TMG database may of course contain fact types ('tag types' in TMG) that are not defined in Family Historian. For example, suppose you have created a custom tag type 'Imprisonment' in TMG, and Family Historian has no equivalent fact type - what happens? The answer is that Family Historian will correctly import all instances of this fact type from your project, but because the fact type is undefined within Family Historian, it will do a poor job of generating sentences for it. Instead of a sentence like "John Smith was imprisoned in May 1961", you might see a sentence like "John Smith experienced 'Imprisonment' in May 1961". Where this happens, you can either redo the import and enable create of fact definitions; or, if you do not wish to do that, you can simply provide the missing fact definition yourself within Family Historian. To do this, open your new Family Historian project and click on 'Fact Types' on the Tools menu. Tick the box labelled "Show Hidden". The list will expand to show all undefined fact types (marked as '<undefined>'). Select each one in turn (e.g. 'Imprisonment' in our example) and click the 'Edit' button. You will be told that the event or attribute is undefined, and asked if you wish to create a new definition for it. You only have to do this once for each undefined fact type. Of course, none of this is necessary if you import create fact definitions as part of the import; so that is still the best option if possible.
Family Historian distinguishes two kinds of 'fact' about a person: events and attributes. Both of them have, or can have, dates, places, notes, media, and source citations. Attributes have an additional field, however: the attribute value. For example, in Family Historian the following are events: birth, death, burial, marriage, divorce. Examples of attributes are: occupation and education. The value of occupation might be 'farmer'. The value of education would be the name of the educational establishment - e.g. 'Cambridge University'.
When you create a custom fact in Family Historian, you have to say whether it is an event or an attribute. For example, Hobby might be a custom attribute. Possibly values for this attribute might include football, sailing, chess, etc.
The difficulty when importing TMG data into Family Historian, is that TMG does not make the same distinction. Occupation and education are treated as events in TMG, and the 'value' is simply placed in the Memo field. This creates a dilemma when importing TMG data into Family Historian. For ordinary events (that is, facts which both Family Historian and TMG class as 'events'), there is no problem. The value of the TMG Memo field can be copied into the Family Historian Note field. But what should we do when importing something which Family Historian classes as an attribute? Should the TMG Memo field be copied into the attribute value, into the Note field, or both?
To make things even more difficult, a Memo may be a multi-line field, containing several paragraphs of text. Attribute values are single-line values only, and expect relatively short values.
By default, when importing an attribute, Family Historian will copy the first sentence of a Memo into the attribute value field, and will copy the entire Memo into the attribute note field - unless this would mean that the value and the note contain exactly the same text (because the Memo consists of only one sentence anyway), in which case the note field will be left blank. However, you can choose other options (see table above).
The principal in any event is the person that the event is 'about'. Some events, such as marriage, are about two people and hence have two principals. In TMG, you can specify a role for both principals and witnesses (other participants). In Family Historian, you can also specify a role for the principals in an event, but you do it by adding them as witnesses to their own event (if a principal is also a witness, generated sentences will be based on their witness occurrence). The only type of role that is not allowed for witnesses is 'Principal', as this is a reserved word (the role, effectively, that all principals have automatically and by default). By default, Family Historian will add a principal as a witness to their own event, if they have any role other than 'Principal'.
In Family Historian, all events and attributes are either Individual events/attributes, or Family events/attributes. Individual events/attributes (like birth and death) have at most one principal. Family events/attributes (like marriage and divorce) can have up to two principals. In TMG, all events and attributes, can have up to 2 principals. If an event is imported, such as occupation, which can only have one principal in Family Historian, any second principal will be added as a witness, with role 'Principal 2' ('Principal', as already mentioned, is not allowed as a role name, but 'Principal 2' is OK). Sentences referring to the second principal will be automatically adjusted (if TMG codes are being replaced) to refer to the correct person.
To learn more principals and witnesses in Family Historian, see Witnesses Window.