Modified July 30, 2020 4:47 pm
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

Customizing TMG™
Data Entry Standards My Way ©MJH

Chapter Contents

• Overview

• Names:

Blank Names, Index Name, Sort Names, Married Name, Selected Name, Name Styles, U.S. Standard Name style, Name Title Field, Name Style sorting and indexes, Name Style Templates

• Dates:

Irregular dates, Old Style, Modifiers, Question Mark, Say/Circa, After, Same-day Ordering, Internal Structure, Sort Order, Sort Date Table, BC Dates

• Places:

F2 Sort Code, L10 Codes, Place Styles, Repository Place Styles, Short Place, Second Site Places, Latitude/Longitude

• My Place Entry Usage: U.S. locations, Non-U.S. Locations, General Conventions

• Surety Values

• Special Characters:

Long ‘s’, Non-ANSI, Special Use

• Memos

• Sources

• Add Person

• Alternate Languages

• Endnotes

Overview

These are standard considerations that I (try to remember to) use for entering data into my TMG datasets based on numerous suggestions from other TMG users and experience with what works for me. Consistency of data entry1 improves report output, searching and the use of standard sentence templates.

The TMG <F2> and <F3> Function Keys can help with consistency by retrieving an exact value previously entered. Pressing <F2> usually will allow searching among a display of previous entries in that field. When used in the Place fields I find the limited entries provided confusing. See my discussion of my F2 sort code for a description of the functioning of <F2> when used in these fields.

<F3> operates on a list of the last fifteen entries in that field. Pressing <Ctrl>+<F3> will display that list. The operation of <F3> depends upon whether the field already has content. If the field is empty it will return the last entry used in that field, which is number one in the repeat list. If the field has contents, TMG will search the list of recent values to find a match to that contents. If it does not find a match it will replace the contents with the last entry used in that field just as if the field had been empty. If it finds a match it will replace the contents with the data entered prior to that matching value, i.e. one number higher in the list. After pressing <F3> the field will have contents of one of the values in the list. Thus pressing <F3> again for this non-empty field will match that contents and replace the contents with the entry prior to that match, and so forth.

Names.

• When entering a new person, see my comment about the person’s ID number.

• Enter ALL names in full, if known.

• Enter names in normal mixed case, capitalize only normal letters.

• Do not capitalize letters that are not usually capitalized (i.e., de Silva). See also my discussion of Name Styles for my use of the PreSurname field.

• Blank Name Parts—A Name tag can have blank fields which specify those name parts to be treated as either missing or non-existent parts, whichever may be meaningful.

For a Primary Name tag if a given name or surname is not known, leave the field blank/empty to indicate the name is missing. A missing given name or surname in a non-Primary Name tag will be inferred from the Primary name as described below and in the discussion of Inferred Name Parts in the Custom Tag Descriptions chapter. While the name part will simply be missing in TMG picklists, there are options in TMG reports (and in Second Site) to specify the text to be output as if it had been entered in the empty/missing GivenName and/or Surname name parts of the Primary Name tag, and only those parts. TMG reports provides for that text to be entered in the option “Empty name text” on the Names tab. Second Site provides for that text to be entered in the configuration field “Strings // Name Strings // Missing”. Both have defaults for that text. You cannot directly enter a name in TMG which is completely empty, including both the GivenName and Surname fields. However TMG will allow a name to be entered with text in some name field but neither of those two, and will permit deleting any text in either or both of these two name parts when editing an existing Name tag. Either action could result in a Name tag with both of these name parts missing.

If it is known that the given name or surname does not exist, enter double exclusion markers ‘--’ as the complete text for that name part in the Primary Name tag. TMG (and Second Site) will treat that name part as non-existent and differently than a missing name part. There is no option to output some globally defined text for non-existent name parts in reports. There simply will be no text output for that name part anywhere. Non-existent surnames are common in early history, as well as some circumstances such as slave names.

If a name part is entered as optionally excluded data (with a leading single exclusion marker ‘-’, or completely enclosed in sensitivity markers2 ‘{}’) and the “Show excluded data” option is not checked on the Miscellaneous tab of the TMG report options (or in the Second Site “Data // Database” configuration), that name part will be treated as if it were a non-existent name part as described above. If the TMG “Preferences // Program Options // Tag Box” option does not “Show excluded data”, that name part will not display in TMG windows where names are displayed, but will display in the Expanded picklist and Project Explorer, and will display but with the leading marker in the Simple picklist.

• Can use the Title or Suffix fields (possibly with leading ‘-’ to allow the option for this part to be excluded) for an identifying phrase, e.g. “-mother of Mary Doe (43)” to distinguish among other entries without this name part.

• Can use appropriate text in the SortSurname and/or SortGiven fields to force an order among others without this name part.

Special issues exist about Names with excluded parts, especially in Name indexes. See the more detailed discussion in the Name Tags—Indexes and Exclusion topic in the Name Tag Types section of the Custom Tag Type chapter.

A special case of blank name parts is a mononym name, where a single name or phrase is used as if it is both the given name and the surname (e.g. Prince, Sting, Sitting Bull, etc.). Usually no other name parts exist,3 so I enter such a name in TMG using the custom Name tag Name-One and a custom Name Style which I call “OneName” with custom labels for the GivenName and Surname fields, and duplicate that mononym text in the Primary Name tag in both (but only) those custom labeled GivenName and Surname fields.

• Middle initials—My currently consistent practice is to not include the period after the middle initial. If a Name variable for only the Given name field is used, the period often causes other punctuation problems. A trailing period also causes problems with the automatic name processing of People fields in a Bibliography.

• Do not use the escape character ‘\’ in a Name-Var name field as it is not recognized as escape and will simply print. However, it may be required (and does no harm) when the name is actually typed in a memo, such as in front of an interior period (e.g. for a middle initial).

• Index Name—A surname can often have a great many variations in spelling. Some users have suggested including an additional custom Name-Var tag type (variously labeled Name-Std, Name-Index, etc.) to record your personal standard for the spelling of that name. I also use my Name-Surname-Sort custom tag type for generating an additional index entry. Adding such a tag to a person will help find them in a list or index both with their names as recorded in sources, but also by this variation. There are several other methods to affect the sorting and display of names in lists and indexes as described below. (See also Name Tags—Indexes and Exclusion in the Name Tag Types section of the Custom Tag Type Descriptions chapter.)
If the person has records with alternate spellings or names, but you have concluded that these are incorrect for some reason and do not want these alternatives to appear in the indexes, do not enter these as alternate Name tags. Instead either explain this conclusion when citing the source, or use a separate Anecdote tag.

• Sorting names—If you simply use TMG’s defaults, names will sort as one would expect. In general the sort order in TMG picklists of names will be based on the output results produced by the appropriate (Surname or Given) Sort template from the Name Style of that Name tag, but the output displayed in those lists will be the results produced by the corresponding Display templates. By default those two types of output will be identical, but can be customized so that their results will differ.

The sort order of names including missing and non-existent names, especially in indexes, is more fully described in the Style chapter since it depends upon the collate sequence used. The treatment and sorting of any missing name parts will depend upon whether or not the name tag is Primary as described in Blank Name Parts above. If it is output with the text defined for missing output, or with inferred text from the Primary name, it will sort based on that text. Any non-existent name parts do not have a text value, and thus all will sort together in the defined position within that collate sequence reserved for blank names.

Both TMG and Second Site provide similar but different options for whether both Display and Sort entries will output in their name indexes. Both these options, the Name Style of the name, and possibly excluded Name Tag sentences, as described below, will effect the entries produced for that name in an index. (See also Name Tags—Indexes and Exclusion in the Name Tag Types section of the Custom Tag Type Descriptions chapter.) They will either produce a single entry based solely on the Display template, or potentially also produce a second entry based solely on the Sort template. Thus if the two types of templates and/or their data are customized to be different, indexes will differ from TMG lists. In summary, name sorting can be customized using four features:

• the text entered in the different fields of the Name tag

• the different templates of the Name Style assigned the tag which may include hard-coded characters

• the TMG collate sequence chosen for the project, or used by Second Site

• options available to control name index output in both TMG and Second Site

The most common sorting customization involves grouping people with similar surnames under some standard spelling, often by using an additional Name tag such as an index name described above. Another method to accomplish this grouping is to prepend a chosen special character on several names to force a “grouping” of those names in either the picklists or indices. Such a character could be entered as part of the name’s text in the Surname and/or SortSurname field of the Name tag. However, it also could be automatically added by including some hard-coded text4 at the beginning of one or more templates of a custom Name Style assigned to their Name tags (like I do to group and sort my different types of Pseudo People names separately from “real” people’s names). Choosing which templates in a Name Style have these hard-coded characters can limit their effect on sorting and display to only indices and/or picklists.

For a more complete discussion of the sort order of names, especially involving leading special characters, see the discussion below of the effect on sorting in both picklists and indexes of hard-coded text in Name Style templates. See also the descriptions in the Style chapter both of the several collate sequences available in TMG, as well as the sequence used by Second Site.

• Married Name—When a woman has prior marriage(s) and only her married name is known (e.g., Mrs. Jane Doe), enter only her Given Name (e.g. Jane) in her Primary Name tag, leave the Surname field blank, and enter a husband’s record and marriage using a standard Name-Married tag with her married surname (e.g., Doe).

• I choose to create a standard Name-Married tag for all married women since I can choose it for use in other tags. I use the default of only including the married surname. I almost never select this tag to be included in reports.

• I also choose to add a custom Name-Marr-Title tag so that I can choose for various tags a Name-Var that either includes or does not include the married title (e.g. “Mrs.”). This custom tag uses the OtherName field and a Married custom Name Style to cause a Picklist entry sorted by her married surname (like the normal Name-Married tag) but including her maiden surname, e.g “Hannah, Mary Ann, Mrs. (née HOWES)”. I usually select this tag type to be included in reports so that it produces an index entry, but exclude any sentence from printing.5

• Some choose to have the Primary Name for a woman that marries to include both maiden and married names but without the “Mrs.” title, e.g. “Jane (née Smith) Jones” and then also include both a Name-Married without the included maiden name but possibly with a title and a custom Name-Maiden tag. This usually causes the combined primary name to be used first in most reports, then all other tags can choose the name variation appropriate for the event. Others include the (a) spouse’s surname in the Suffix of the maiden name tag, and/or the maiden surname in the Suffix of the married name tag. I do not use these tags in this way as I expect to use the Suffix field for its intended purpose.

• Enter a Name-Var or appropriate custom name tag type identifying a given name variation in the Name group showing a person’s desired given name at any time, if different from that in the Primary name. Only a name defined by a tag in the Name group can be selectively used for the sentences of other tags6. Leave this Surname field blank if it is the same as that in the Subject’s Primary Name tag.7 (See also the discussion of Inferred Name Parts in the Custom Tag Descriptions chapter.) If known, include a date or date range associated with this name, such as the date range a person held a military rank/title. The number of name tags is unlimited, and each can have its own tag name, name style and sentence.

• Review ALL name tags for consistency when changing the primary tag.

• Distinguishing information can be added to one of the name fields (e.g. suffix) with the optional exclusion marker (leading ‘-’) to aid in selecting the correct person in a picklist. Or use a special name style.

Name Styles allow significant customization to how a name is displayed and sorted. Currently I primarily use this feature for custom name styles for my custom Pseudo People (such as Census, Location, Source, and Repository), and my custom Name-Marr-Title tag.
(See the following: Census styles, Location styles, Source style, Repository style, AllFields style, Married style, OneName style, SurnamePreSort style. See also further discussion of Name Tag Styles as part of the general discusson of custom name tag types.)

• The default U.S. Standard Name style only outputs the fields of Title, GivenName, Surname, and Suffix. To output any of the other fields (Prefix, PreSurname, or OtherName) a custom Name Style must be defined and used. Since you cannot modify the default Name Style to include all of these name parts, you must create a custom style for that purpose. For this reason I have created the custom name style “AllFields” which outputs all possible fields (see the Name-Var tag type). I also created the name style “SurnamePreSort” and a custom name tag type (Name-Surname-Sort) for dual index entries for names with non-empty PreSurname fields.

• Custom Name Styles with custom labels are especially useful for very special naming cases,8 or foreign naming conventions which are different than the American standard. Common examples are: Iberian Style (Spanish & Portuguese), DitName Style (French Canadian), Toponymic Name Style such as farm/sub-farm names (Norwegian, etc.), Patronymic Name Style (Norwegian, etc.).9 Custom Name Styles with custom labels will aid data entry of “non-standard” names by modifying the labels of the name part fields to better indicate what data should be entered in that field. Right Click on a field’s label and choose “Modify labels of this level” to add or edit a label name. That will add the custom name to the drop-down list of labels for that field. Now selecting a different label name will automatically change that field’s variable name to this new label name in any template where that field is used.

• When creating a new Style, create any custom labels first and then use them in the templates. If you now select one or more custom labels to use in this Style, click the “Reset” button for a template and the program will change that template’s variables to the custom label names. Custom Name Style names will be truncated to max 100 characters.

• Two different fields cannot have the same custom label among all defined Styles, even if that label is not used in this Style.10 For example, you cannot define a custom label for Field 1 of “Blank” for use in one Style, and then try to define a custom label for Field 2 also spelled “Blank” for use in a different Style. For this reason for each field 1 through 9 I created the custom labels Blank1, Blank2, … Blank9 for use in any Style. I select that custom label to indicate that the Style does not use that numbered field.

• Be aware of an unexpected use of the Title field if GEDCOM import or export is used. On Import the GEDCOM Name part NPFX is imported into the TMG Title part of the Name tag, not the Prefix. This was done because originally11 the only TMG Name tag fields were Title/Prefix, GivenName, Surname, and Suffix. But on Export, with the Export option “Name NPFX/NSFX” the TMG Name/Title part is placed in a completely separate GEDCOM Event structure called TITL, which is not part of any NAME structure. The TMG Utility could be used to move all Title data to the Prefix field so that it would later export as NPFX. However, either the default U.S. Standard Name style would have to be customized to output the Prefix instead of the Title, or a custom Name style would have to be used for all Name tags that had data in the Prefix field. See also a possible custom Name-Title tag type for this issue.

• WARNING: When importing12 Name tag types which have been set to a default Name Style in the exporting dataset which is other than the dataset default, the import may link the tag type to an unintended style. (See Importing Tag Types in my Import/Export chapter.)

• As of v6, there are four ways to apply a Style to a tag: Select it manually, Inherit it from the default for the project/dataset, Inherit it from the Tag definition, Inherit it from the ‘Setup’ for the Person Entry window

• The TMG Help says that conditional brackets are assumed for Name Style variables. Name Style templates do not recognize entering explict conditional brackets (‘<‘ and ‘>’). However, the parentheses characters themselves have a conditional aspect.13 The characters outside the ‘[]’ bracket characters for the variables are not conditional and the program appears to always output such characters.14

• If special values are desired to be added to the name, such as fixed text15, it is suggested to create a Name Style in order to set appropriate name display Templates, and each often different. This ensures consistency and allows the sort to include or exclude this fixed text as appropriate. One example of such a name style is my custom Married Name Style which is default for the custom Name-Marr-Title tag type to insert the parentheses and “née” in the Templates for a combined maiden and married name such as Mrs. Jane Jones (née Smith) where “Jane” and “Smith’ can be entered or inferred in the GivenName and Surname, and “Jones” in the OtherName. Another would be for inserting the quotes in the Templates for a nickname style such as Robert “Bongo” Richards where the nickname is entered in the OtherName. A third example is my use of prepended hard-coded special characters to names of pseudo people to cause them to sort separately in name lists from “normal” people names.

• Both TMG and Second Site use output up to the first hard-coded comma from the Surname Display template as the value of the surname for grouping in its index, but only based on a comma that appears as hard-coded text in that Name Style template and ignores commas that occur in the name data itself. Thus a hard-coded comma in the Surname Display template text is essential to separate the output of the leading surname data from the rest of the output which will be used by the index as the distinguishing text for this specific person with this surname.16

• Effect of Name Styles on sorting and indexes—See the discusson of sorting names above for the basics about sorting this data. As that indicates, sorting can be customized using a combination of the data in the Name tag fields as well as the appropriate Name Style templates which refer to those fields. In the Name tag the SortGiven and SortSurname fields by default are initialized to be the same text as the GivenName and Surname fields. Also by default the only difference between the two sets of Sort and Display templates in a Name Style is that the Sort templates refer to the Name tag’s SortGiven and SortSurname fields instead of the tag’s GivenName and Surname fields. But these two sets of templates can be customized to produce different results by having different structures and even including differing hard-coded text in each template,17 and the text in the two Sort fields of the tag can be entered to differ from their corresponding Display fields.

In TMG although the same by default, whether or not the output results of a Sort template differ from the corresponding Display template results, the picklists will always sort based on the results of the Sort template but will always display the name using the (potentially different) results of the corresponding Display template. Such a difference either may be due to customizing differing field order, structure, or the inclusion of hard-coded text in the two templates, or due to entering different text in the two sets of referenced fields. Having the display different than the sort due to this customization can make it appear that a name is sorted out of the order of the text displayed.

The Name Style templates can also affect the entries in Name indexes. (See also Name Tags—Indexes and Exclusion in the Name Tag Types section of the Custom Tag Type Descriptions chapter)

TMG has an option involving the Name Style templates within some reports (Journal, Family Group Sheet, Individual Narrative) which affects whether only the Display or also the Sort name entry from a Name tag will output in a TMG report People (Name) index. There is a check box on the Indexes page of those Report Options named “Also use sort template”. If you run a report with that box not checked, only one entry will be included for each appearance of that name in the report and will be sorted and displayed based solely on the output results of the Display template. This sort order may be different than the picklists since the (possibly different) Sort template results are ignored for this entry. If you run a report with that box checked and the output results of the Sort and Display templates differ in any way for a name, the Name tag also will produce a second entry in the index for each appearance of that name, which is both sorted and displayed based on the Sort template output results. Further, if multiple Name tags for the same person would produce identical entries due to the structures of their Display and possibly Sort templates, only one entry from those identical results is included in the TMG report index for that person.

Second Site provides a similar but slightly different option affecting whether only the Display or also the Sort name entry from each Name tag will output in its index. The configuration option in Data // Names of “Ignore SortSurname and SortGiven” affects whether Second Site will add a second entry to its index from a Name tag. Opposite to the similar TMG option if this option is checked, Second Site will add only one entry to the name index even if there are differences in the text entered in the two fields or in the two template output results due to structure or hard-coded text. But this one entry will both sort and display based on the full results of the Display template, including any hard-coded text. Again this sort order may be different than the TMG picklists since the (possibly different) Sort template results will be ignored. If this option is unchecked, which is the default, Second Site will compare the text entered in the SortSurname and SortGiven fields to the corresponding text entered in the Surname and Givenname fields of that Name tag. Differently than TMG, Second Site compares the text entered in these two sets of fields, not the output results of the tag’s two Display and Sort templates. Thus even if hard-coded text or structure differences exist within the two templates which would cause the two output results to differ, that will not cause Second Site to treat the two formats as different so long as the two sets of text are entered the same. If the option is unchecked and the text entered in the two fields differ, then Second Site will include a second entry in the name index sorted and displayed using the full output results of the Sort template, with any hard-coded text from that template included in these results. In Second Site multiple name index entries produced from multiple Name tags whose results happen to identically match other entry results, even if these entries are from tags for the same person, will each produce their own separate index entry.

• Template types available in Name Styles are:

Dates.

• I select the “dd Mmm yyyy” date format in File > Preferences > Program Options: General. TMG permits you to enter a date in a number of ways, e.g. text or numeric, and different forms of the same modifier. No matter which format was used to enter dates if it is not irregular they will be displayed using the Preferences selected Date Format. Regardless of this Preferences selection they will be printed in Narrative report based on the date option chosen for the report in the Dates Options tab (if there are options), the default being “dd Mmm yyyy”. The default output of dates will remove leading zeros. One of the options on the Dates Options tab allows choosing to retain leading zeros. None of the “List of” reports have such a Dates Options Tab, thus they will output dates based on the Preferences display selection with leading zeros removed. For these reports you cannot reliably know the number of characters a date will output.

• Irregular dates are those whose data as entered does not conform to one of the recognized input formats. TMG will warn that it views the data as an irregular date and require confirmation that you wish to use it anyway. Dates with internal parentheses ‘()’, braces ‘{}’, or brackets ‘[]’ are interpreted as irregular dates,19 as are dates with some other special characters.20 The following are the significant issues I have discovered so far in using irregular dates:

• An irregular date can only have a maximum of 29 characters.

• An irregular date will output as entered regardless of a report’s Dates Options.

• The sentence Date variables will output the data as entered but cannot determine the year.

• The sentence Age variables cannot determine the subject’s age for this tag.

• TMG filters cannot search for anything concerning the contents of an irregular date, only determine that it is irregular.

To force a date to be irregular which would ordinarily be treated as regular (e.g. “1920s” will be treated as year/month and become “Sep 1920”), either enter it with surrounding quotes (which will output in reports), add a non-breaking space21 (Alt + 255 on the numeric keypad), or append a calendar reference. A calendar reference is especially useful for entering dates recorded in a source as “Old Style” which may be outside the normal range set in Preferences for such dates, e.g. “5 Jan. 1571/2 CE”. The ‘CE’ will make it irregular so it will not be treated as a “between” date. Even if the date is forced to be irregular, it is recommended that you enter a regular Sort Date unless you wish it to sort as an irregular date.22 Of course adding some text which is clearly not a month name will always force a date to be irregular (e.g. “the 1920s”).

• In general you can enter a date using any of the nine Date formats described in “Program Options: General” regardless of the display Preference format that is set there.

• Neither exclusion markers (‘-’, ‘--’) nor sensitivity braces (‘{}’) may be used in Date fields.

• If a complete date entry is a set of all numbers, with either the first or last number greater than 31 and one of the other numbers greater than 12, then TMG will understand which is the day, month and year regardless of their order entered or the Preference display setting.

• To avoid confusion always enter the year as four digits, with leading zeros if necessary, so that TMG will know it is a year and not interpret it as digits representing either a day or month.

• If the complete date entry is all numbers and the day is not greater than 12, TMG must guess which is the day and which the month based on the Preference in “Program Options / General”. For example, if “8/11/1864” is entered and the Preference is set to any of the “month first” display formats, then the date entered will be interpreted to be August 11, 1864. But if the Date display Preference is set to a “day first” format, then TMG will interpret this entered date to be November 8, 1864.

• An all-number date with an unknown month, day, or year can always be entered as a complete date by entering zeroes for the unknown value, e.g. 0/5/1884. A month, day, or year value of zero is a holder for an empty field and TMG will assume the day/month order entered follows the selected display Preference. Entering an incomplete date (one that does not have “something” for all three of day, month and year) may give unexpected results.

• If only two of the three date numbers are entered the date is incomplete and TMG must guess what is intended. If the first is less than 32 and the second is greater than 31, the second is assumed to be a year and the first is assumed to be a month regardless of the display Preference. If the first number is greater than 31 it is assumed to be a year and the second is also assumed to be a year for the purpose of entering a year range. Thus entering “1884.5” will be interpreted as “between 1884 and 1885”. If both of the two numbers are less than 32 the year is assumed to be missing and the month/day order will be interpreted to match the display Preference. If only a single number is entered which is greater than 31 it will be interpreted to be only a year.

• The date on which the new year changes has been different than January first in the past. When that change occured differed in various countries. Those dates which occur in the month of January and beyond until the new year but are still considered the same year as was in December are often called “old style” dates. For any date entered with a single year, TMG always assumes that date is entered as if the new year began in January of that specified year. For example, a date entered as 2 Feb 1723 will be assumed to be in the same year and before the date 5 Sep 1723. If a date is known to be “old style”, which in TMG is expressed as a double-year date (e.g. 2 Feb 1722/23), you must use special date entry formats to cause TMG to store it as a double-year date.

The only way to create a double-year date is to use one of the special date entry formats below, and that date must fall within the “old style” date range set in File > Preferences > Program Options: General. The only function of this date range is to change the meaning of some normal date entry formats to instead recognize the entry as a double-year date within that range. There is a remaining bug where some valid forms of “old style” date input are interpreted as irregular. The default “old style” date range is 1583 to 1752. If you want to enter double-year dates outside this range, you must change the beginning or ending year in File > Preferences > Program Options: General so that the special codes will be recognized. If the date range is now changed to no longer include that date, the existing double-year date will remain a double-year date.

Double dates entered within the “old style” date range change the normal meanings of the ‘/’, ‘-’, and ‘.’ codes to no longer specify “between” the two dates. Any use of text such as “btw”, along with these codes instead of the word “and”, with two consecutive years within this range will be interpreted as an irregular date. Further, appending the text ‘OS’, which would normally cause a single-year date to be considered irregular, now will also trigger a two-year date. Note: a single year date which is within the “old style” date range and appended with the ‘OS’ code is specifying the second of the two years. Examples of valid “old style” date formats are:

• Old Style converted to 24 Feb 1699/0, entered as:

24 Feb 1700 OS, 24 Feb 1699/0, 24 Feb 1699/1700, 24 Feb 1699-1700, 24 Feb 1699-0, 24 Feb 1699.1700, 24 Feb 1699.0

• Old Style converted to 24 Feb 1629/30, entered as:

24 Feb 1630 OS, 24 Feb 1629/1630, 24 Feb 1629/30, 24 Feb 1629-1630, 24 Feb 1629-30, 24 Feb 1629.1630, 24 Feb 1629.30

but 24 Feb 1629/0, 24 Feb 1629-0, and 24 Feb 1629.0 are considered irregular.

• In general do NOT convert an irregular date specified in a source for entry in the Date field, i.e., enter “2nd Sunday after Trinity in 1709” in the Date field, acknowledge, and ignore the irregular date notice. However, note the issues with using irregular dates above. Alternatively, leave the irregular date in the citation detail along with a note that defines a conversion to a standard date, then use the converted standard date.

• Do convert dates as necessary to make them regular Dates for the Sort Date field so that they will “sort” among regular dates if that is desired, e.g., enter “9 Jun 1709” as the Sort Date for “2nd Sunday after Trinity of 1709.”

• The spelling/text of the qualifier or modifier words that automatically output on reports for the various Date forms can be altered by defining a custom language.

• Modifiers—TMG has the following eight internal numeric modifiers to a Date. These also affect the date’s sort order. Most of the eight numeric codes have several alternative modifier texts which may be used to enter that type of modifier, but once entered it is converted to the numeric code which is the basis for their sort order and all subsequent display/output. For example, you can enter “Estimated” but TMG will convert that to its internal code ‘1’ and will always output/display some form of “Say”, either spelled out or abbreviated depending upon the output. See also GEDCOM Export: Dates.

GEDCOM defines two other modifiers which TMG does not include among its “regular” date modifiers. “Calculated” with the GEDCOM code ‘CAL’ is a date which was calculated mathematically from other data, e.g. a birth date calculated by mathematically subtracting a precise age at death from an exact death date. “Interpreted” with the GEDCOM code ‘INT’ means that the date was interpreted from knowledge about some other recorded data which includes a date phrase, e.g. interpreting the AD year from a phrase like “the fifth year of the reign of Queen Mary”. TMG’s irregular date format can be used to produce these two GEDCOM date forms, up to the maximum of 29 characters allowed in TMG’s irregular dates. If properly formatted an irregular date form will export to GEDCOM in a format recognized as one of these special modifiers by GEDCOM. For example these two TMG irregular dates:

CAL 14 May 1901

INT 1733 (Fifth Mary R)

• Question Mark—Any regular Date form, with any level of specificity, can be entered with a single trailing ‘?’ after the complete Date form, which is intended to express uncertainty. TMG will not consider it irregular, and it will sort immediately after the identical Date form without the question mark. Computed ages (whether as a sentence variable, the person’s Age in Other Info26, or the Age column in the Details window) based on dates with a trailing question mark will also print with a trailing question mark. Should use surety associated with a date from a source. One suggestion is to imply that a Date form with a question mark would have one less surety than the same Date form without the question mark. For a Burial with an empty unknown actual date I often use a Sort Date of the Death date with a trailing ‘?’ to force the tag after the death.

• Say versus Circa—The TMG meanings of “say” (which is the same in TMG as “estimated”) versus “circa” (which is the same in TMG as “about”) reportedly came from Robert Charles Anderson’s definitions from his “Great Migration” series. To paraphrase from that work, “say/estimated” is less precise and sorts before “circa/about” which is relatively precise, but the exact precision of either is not defined. The meaning of these modifiers in your reports is simply what you intend. If your use is not “standard” or you have in mind a specific amount of precision, you can always explain your use in a Forward to your report.

• After—The sort order for the TMG Date form “after ‘date’” should be read as “sort immediately after the Date form of ‘date’”, e.g. ‘after 1901’ means “sort immediately after the Date form of ‘1901’”. Some consider this a controversial sort order since missing months and days take on the value of zero and the “after” form will sort before dates with non-zero values, e.g ‘after 1901’ sorts before most other date forms containing 1901, e.g before ‘Jun 1901’. To overcome this programmed sort order you could leave the Date modifier as “after ‘date’” for reports but enter a comparable form of Sort Date of “before ‘next date’” where the “next date” has the same TMG Date form and level of detail as the “date”. For example, using the comparable Sort Date of ‘before 1902’ for a report Date of ‘after 1901’ will sort such tags after all date forms which contain the year 1901.

• For multiple events that actually occur on the same date but where you want to “force” a particular order, most users simply put a Sort Date for the “second” event one day later, etc. (See also Date Sort Order.) However, I prefer to keep the “real” or “report” date as part of the Sort Date, and use a modifier to force the order. All of the following Sort Dates contain the “real” date of 21 July, will sort event tags with a “report” date of just 21 July in the order below, and these tags will sort between any tags with similarly constructed 20 July and 22 July Sort Dates:

• The following is the internal storage structure of both Dates and Sort Dates. Since the Sort Date controls the sorting of the tag (which by default is a copy of the Date field) this structure of that date should explain all the other sort order examples described here. See also Date Sort Order below.

Irregular Dates include blank dates since all its values are zero. Due to the initial zero in the first character Irregular Dates will sort alphanumerically before all regular Dates but after all blank Dates.

Regular Dates (should normally be used for any Sort Dates if you want them to “sort” in a normal fashion)

An “Old Style” date will be stored internally using the number of the later of the two years. This ensures that such dates will sort after any dates in the 12th month of the earlier year and before dates in later months in the later year. The value one in Character 10 ensures that the date will be output using two years according to the date style chosen.

• Sort Order—Dates will sort and be compared for “before/after” using their internal date structure in the example order shown in the table below based upon the amount of content and specificity of the date and any modifier. All TMG Filters on dates with modifiers will also be based on this described sort order.

For example, consider a filter condition for events of “Date // > Comes after // 1901”. As shown in the table a date value of just “1901” by itself comes after “circa 1901” and before all other more qualified dates in the year 1901. Thus this condition will include all 1901 dates with a value which has more than just the year (e.g. “Jun 1901”), but will not include any events whose date value is just “1901”. It will also not include “say 1901” or any events whose date value is “circa 1901” regardless of the range set for the meaning of Circa in Preferences > Current Project Options > Advanced.27 As an alternative example consider the filter condition “Date // > Comes after // before 1902”. This will include events with date values of “circa 1902”, “say 1902”, and just the year “1902” and any dates containing 1902 or later years, but will exclude events with a date value of “before 1902” and any events with a 1901 or earlier year.28

Blank Dates sort before all other Dates in reports. Blank Dates can be made to sort last in the Person View but this preference does not affect reports. See Preferences>Program Options>Tag Box. Irregular Dates sort before all regular Dates but after blank Dates. If you do not know any dates, you may always put a Sort Date “guess” to ensure the tag sorts as you wish since Sort Dates change the sort order in the display and in reports. Sort Dates usually should be regular (except see irregular BC dates below) to ensure proper sorting and are never printed. See also John Cardinal’s TMG Utility to add “logical” Sort Date guesses if missing.

Multiple identical dates will sort together, but their order within that group is unpredictable. To ensure a specific order, use different Sort Dates so the dates are not identical. See same day ordering above.

For clarity and simplicity, the table below assumes that both the Date and Sort Date are identical. If the Date and Sort Date are different, it will display according to the Date but will sort based on the Sort Date. These displays are with the “dd Mmm yyyy” Date format in File > Preferences > Program options: General. The amount that displays in the PV is dependent upon the width of the Date column. These examples show what will display with full width. There is a fixed form of truncation/abbreviation so that differing values display the same (e.g. between, or, from), and the truncated display uses abbreviations (‘bt’ and ‘fr’) not recognized for data entry.

• For dates that are before year 1, irregular dates can cause both the output and sorting to be appropriate.29

• Put the actual date in the Date field but with trailing text like ‘BC’ or equivalent so that TMG will recognize it as an irregular date30

• Use irregular Sort Dates to force them in appropriate (reverse numeric) order. This is accomplished by entering the “9’s complement” of the year in the Sort date field, but again use trailing text like ‘BC’ or equivalent so that TMG will also recognize it as an irregular date

A “9’s complement” is created by subtracting the actual ‘BC’ year number from a base number which is all 9’s and has an equal or greater number of digits. For all ‘BC’ dates in your dataset you should use the same base which has the same number of 9’s digits for all these subtractions.31 The number of 9’s digits needed is dependent upon the number of digits in the oldest ‘BC’ year. For example, if your oldest/biggest ‘BC’ date in your dataset is “3000 BC”, then a four digit or bigger 9’s complement base will work, i.e. subtract all your ‘BC’ years from the base of ‘9999’. If you are unsure of the biggest/oldest BC year expected, always using the same 9’s complement base which is too many digits will not hurt.

Since TMG sorts all irregular dates in alphanumeric order prior to all regular dates, this trick will sort all these irregular ‘BC’ Sort Dates in the proper order before regular (CE) dates. Reports will print what is in the Date field but events will be sorted in correct (reverse numeric) order because of their “9’s complement” irregular Sort Dates. For example:

Places32

(See also my discussion of Location “pseudo” people.)

A place is a single entry in the Master Place List made up of the ten place fields33 that are combined together for output based on the one Place Style associated with that place entry. A place is not stored with a tag or repository, instead the tag or repository links to a single place entry in the MPL. If you change the MPL entry, all tags or repositories referencing this place entry will change their output. Most customization that affects place data entry is accomplished by unusual use of place fields, and/or Place Styles which can include or exclude certain place fields and control their output. Due to a remaining bug, take care when using the escape character (‘\’) when entering place data.

• Unusual uses of place fields — There are many discussions about the limitations of the location structure and users often customize by unusual uses of place fields that they do not otherwise normally use. Some reserve the Addressee [L1] field for special uses. Since many users of TMG do not use the LDS Temple [L10] field, this field is often suggested for customized uses.

[L1] F2 Sort Code — Maintaining a clean Master Place List (MPL) is an issue to me. Unwanted duplicates or unwanted changes to the MPL are often introduced due to the clever and (probably) useful but non-intuitive (to me) functioning of the F2 key as it applies to searching for existing places. In searching for an existing place in the MPL, F2 finds all entries that match what is entered in the field containing the cursor and higher level fields from that point on. All lower level fields are left blank even though the MPL may have multiple matching entries with non-blank lower fields. They are left blank because TMG has no way to determine which one you want. The only way to ensure that when you use F2 you search the entire MPL is to force a non-blank value in the Addressee [L1] field of every place, and always put your cursor in a blank [L1] field when you use F2.

One proposal34 for a non-blank [L1] field was to always enter a custom “F2 sort code” to cause like places to sort together in the F2 list. Multiple MPL entries can have the identical F2 code, and they will group together but sorted by their subsequent place fields. F2 code abbreviations for locations should follow some recognizable standards, but since this code is never output, it should be abbreviations you will most easily remember. If you use this [L1] F2 sort code you may wish to have a custom Place Style to avoid normally outputting this Addressee field. I use such a code, as shown in my place fields usage tables below, but instead of a Place Style to prevent outputting the code I currently precede my F2 sort code with double exclusion marks “--”. I also do this to avoid it ever displaying on the Person Details views, because the Place Style does not affect that output. However, this prevents it from ever being output, even on Lists of Places reports where I might want to see it; but I consider this an acceptable price for the convenience of this sort code.

[L10] Place Style Code, et al. — Those who do not need or use location subfield [L10] for its designed purpose of LDS Temple, suggest a variety of uses for this field, such as a “chart place”, the “current” location name, clues about the location, or “codes” describing the intended Place Style. Since charts do not have the option of either short place or state abbreviations, some enter an abbreviated location into [L10] as a “Chart Place” field and only include [L10] in charts. Another use of [L10] is to record the full “current” name of a location whose name has changed over time. This is often combined with setting the place Start and End dates for this “old” place name. [L10] can then be used in custom tag sentences to refer to the current place name.

There is no mechanism to identify when last you edited a specific tag. The Last Edited date35 in the Other information box on the Details screen will be automatically updated for that person for a variety of reasons which you may not consider to be “editing” a tag; thus that date is by person not by tag. To track tag editing information one could use [L10] to manually enter the most recent date of editing that tag. The disadvantage of this method is that it will severely clutter up the MPL with unique places. I do not currently track editing at this level of granularity.

Since only one Place Style can be associated with an entry in the Master Place List, but it was not displayed prior to Version 9 and could be inadvertently changed, some recorded a “code” for the intended Place Style and other Place entry information in [L10].36 While the Place Style name is now displayed in the Master Place List, some still find useful a code indicating the preposition that is included in the Place Style, whether there is a Short Place, Comment, or Exhibit attached to the MPL entry, and the start/end dates if specified. Examples of this system are:

    -INprep +S +C +E YYYY-YYYY

    preposition= “in” Place Style, has short place, has comment, has exhibit, year start-year end

    -ATprep -S -C -E YYYY-

    preposition=“at” Place Style, no short place, no comment, no exhibit, year start-no year end

• Place Styles — The implementation of Place Styles in TMG is largely counterintuitive and often confusing.

• You can only add a new “Place” Style type in Tools > Master Style List. You first must define the Style before assigning that Style to any place entry. Custom Place Style names will be truncated to max 100 characters.

• When creating a new Style, create any custom labels first and then use them in the Output template. Custom label names will be truncated to max 20 characters. If you select one or more custom labels to use in this Style, click the “Reset” button for the template and the program will change that template’s variables to the custom label names.

• Two different fields cannot have the same custom label among all defined Styles, even if that label is not used in this Style. For example, you cannot define a custom label for Field 1 of “Blank” for use in one Style, and then try to define a custom label for Field 2 also spelled “Blank” for use in a different Style. For this reason for each field 1 through 10 I created the custom labels Blank1, Blank2, … Blank10 for use in any Style to indicate that the Style does not use that numbered field.

• The TMG Help does not mention conditional brackets associated with Place Style variables. Place Style templates do recognize the conditional brackets (‘<‘ and ‘>’) around Place variables.
If an Output template contains an unconditional variable and this MPL entry does not have a value for that variable, the text output depends upon the label chosen for the variable and the Language in use.37 If the system default variable label is used for that field (either the numbered ‘L’ labels or the default system name for that field), an appropriate “unknown” text for that Language is output. However if a custom label is used for the unconditional variable in the template, then the custom label is the only text output with no “unknown” text qualifier.

• Any characters in the Output template inside a variable’s conditional ‘<>’ bracket characters but outside the “[]” brackets which identify a variable name are also output by TMG if that variable is output. Any characters outside any conditional ‘<>’ bracket characters are not conditional and the TMG program will output such characters.38 I generally choose to include any fixed characters associated with a specific field variable (especially punctuation and spaces) within the conditional brackets of that variable.

• WARNING: When importing39 tag types which have been set to a default Place Style in the exporting dataset which is other than the dataset default, the import may link the tag type to an unintended style. (See Importing Tag Types in my Import/Export chapter.)

A defined Style can be applied manually to a specific place entry by directly editing the entry in the MPL, clicking the “Place style” button, and assigning the desired Style. In addition, there are four ways by which a Style is applied to a place entry in the MPL linked from a tag, whether creating a new location or modifying an existing location entry:

• Inherit the Style from the default for the project/dataset when a single tag is created, or when the Add Multiple People40 feature is used which may create multiple tags.

• Inherit the Style from the specific Tag Type definition when a single new tag is created, but not when the Tag Type of an existing tag is changed.41

• Inherit the Style from the ‘Setup’ for the Person Entry window when those tags are created.

• Manually clicking the “Place style” button, and assigning the desired Style, when creating a single new tag or editing an existing tag.

Only one Style may be associated with a given unique place entry in the MPL. If you change the Style from the MPL the change simply happens, since you are changing the unique place entry itself. If you change the Style for an existing place entry when editing a tag, you get a Warning42 essentially asking “Are you sure?” where “No” will avoid the style change. If you say “Yes” then not only this tag but all other tags linked to this place entry also will have their place style changed. A place Style is not stored as part of the definition of each tag. All tags simply link to a place entry in the MPL which has a single unique Style associated with that place entry.43 However, a new place entry can only be created as part of the definition of a tag or Repository.

TMG provides no way to output to a report the Place Style associated with entries in the Master Place List.44 As of Version 9 the Place Style for each entry is displayed in a sortable column in the MPL.

Linking an MPL entry with a custom Place Style to a Repository allows you to display that custom Place Style’s field labels on the Repository data entry screen (useful especially if you are working in a different language than English) but the style’s templates are never used to output this place. While which fields will output for this repository place can be changed due to the Report Definition option for Places, they will never be based on the place style assigned to this place record. As explained for the [REPOSITORY ADDRESS] source element, repository place fields can be selected for output but the effect of the various report options is different for repository places that for all other places. Just like tags, neither a place nor a Place Style is stored as part of the definition of a repository. Just like tags, all repositories simply link to a place entry in the MPL which has its associated style.

It is not possible for the same place entry in the MPL to be used in different Tags or Repositories but differing only in their Place Style. Some data must distinguish different entries in the MPL so that they can remain separate unique entries in the MPL, each with their own single Style. The Tag or Repository must then link to the appropriate MPL entry with its specific desired Style. If you wish to have two place entries in the MPL where both have the exact same “location data” but have two different place Styles, at least one data field must differ between the two place entries other than the just the place Style being different. The simplest way I have found to do this is to first define a new dummy place in a tag definition to create an entry in the MPL. Then open the MPL and edit that dummy place entry so that all its data fields now have the desired same “location data” as an existing entry, but have different place styles and have different text in the Comment field (possibly mentioning the Style). The different Comment text is enough to ensure uniqueness between the two MPL place entries and thereby allow their location data to be the same but their Styles to be different.45

• Short Place — There is a default for a “Short place” template both in Preferences / Program Options / New Project Defaults for creating new projects, and in Preferences / Current Project Options / Other for this project. Unfortunately there is a bug in the final version where you can change this project’s short place template, but that change is lost when the project is closed.46 The “Short place” field in a specific Place record in the Master Place List can be viewed somewhat as an additional separate Place Style template. In previous versions location variables were not recognized in that field, only raw text. As of Version 8 either explicit [Ln] variables or label variables (e.g. [City] ) are recognized, so you can populate multiple locations in the Master Place List with the same Short Place template with the F3 repeat key. However, all variables are unconditional, so will give the “unknown” text in reports if the field is empty.47 If the “Use Short Place field” option in various reports, usually on a “Places” tab, is specified and no short place text has been entered in that location record’s “Short place” field, location output is constructed based on the “Short place template” location variables specified in Preferences / Current Project Options / Other.48 In other words by default the Short Place output will be based on the project-specific template, but can be overridden by specific text for that specific location.

An MPL entry with a custom Short Place template linked to a Repository will never output the fields based on that Short Place template. If the Report Definition option for Places is set to use Short Place templates, the [REPOSITORY ADDRESS] will output based on the project’s default Short Place template.

• Places and Second Site — If you use custom styles and especially the “Short place” fields and your main output is Second Site49, then you might consider setting the Second Site parameter Data.Places.Place Format to “Full, then Short”. From the Second Site Help file:

“The Place Format property controls whether the Full Place or Short Place format is used. As in TMG, the short place is either a literal string assigned to the place via the Master Place List (MPL), or, if that is empty, the short place is the result of interpreting the Short Place template which is defined in the TMG preferences.

“The Full, then Short choice operates as follows. The first time a place is shown in a particular person entry, the full place is used as the value of [L]. For all subsequent references to the same exact place for the same person, the short place is used as the value of [L].

“If the result of processing the Short Place rules (use the literal value, then use the template) is an empty place, then Second Site will substitute the full place. So, if the Short Place template is “<[L3],> <[L5],> <[L6]>” but the L3, L5, and L6 fields are empty, then Second Site will use the full place value.”

• Latitude and Longitude—One way to identify that a location which has changed its name over time is really the same location is by entering its latitude/longitude in the MPL record. With modern GPS locators this can also aid in locating an obscure location, such as a private cemetery or specific gravesite. In addition Second Site has options and features to generate a hypertext link on the Place Index to a map of the place.

• WARNING: If Preferences / Program Options / Prompts / Validate LAT/LONG values is disabled, any value entered in this place field is treated as text and not a Latitude/Longitude value.

• Prior to Version 8 the original, and standard, TMG data entry convention was only “ddmmssndddmmssw”50

• As of Version 8 TMG accepts decimal values, and will convert the old non-decimal Latitude/Longitude values to internal decimal values. Any decimal value entered with less than six decimal places will be converted to the decimal value of the nearest whole degree/minute/second value. Thus more precise decimal values can be stored than degree/minute/second, but only if entered with a full six decimal places including any required trailing zeros.

• The two decimal values should be separated by a comma, space, or tilde. There should be no interior spaces unless one space is the separator in place of either a comma or tilde.51

• A negative latitude must be preceded by a backslash (escape character) to distinguish the leading minus sign from an exclusion marker. If a leading minus sign is entered without an escape character, TMG will automatically add an escape character ‘\’ between that minus sign and the LatLong value. This highlights and separates the (presumed) single exclusion marker from the LatLong value, e.g. -\22.906800, -43.172900. This separator escape character will not be added by TMG until after the cursor leaves this field and thus may not be noticed during entry. If a southern hemisphere value is desired to be single excluded, two negative signs plus the escape character are required: e.g. -\-22.906800, -43.172900.

• A hypertext link to a map based on the latitude/longitude can be added to memo text in an event, usually used for places which are not entered in the MPL. However, due to a bug52 in TMG concerning the use of the ampersand character in a URL, the actual link text in such a memo should be restricted to Second Site by use of embedded format codes. For example, the following code53 in an event memo will output the Lat/Long values as text in the TMG report, but produce a link in Second Site to a Google satellite map with a marker at the Lat/Long values:

[HID:][SS-HID:][:HID]Approximate Latitude/Longitude: [HID:][:SS-HID][SS:] <a href="https://www.google.com/maps/?t=k&amp;q=[:SS][:HID] 40.431471,-78.201456[HID:][SS:]">(Google Lat/Long map)</a>[:SS][:HID]

• For conversions of the UK system to the common Lat/Long see:

https://www.streetmap.co.uk/streetmap.dll?GridConvert?name=441500,332500&type=OSGrid

Other sites searchable by location usually with LatLong information:

<http://atlas.nrcan.gc.ca/site/english/index.html>

<http://www4.rncan.gc.ca/search-place-names/coordinates.php>

<https://www.heavens-above.com/SelectLocation.aspx>

<http://historicalmaps.arcgis.com/usgs/>

<https://www.bing.com/maps/>

<https://www.jewishgen.org/Communities/LocRad.asp>

<http://www.globalgeografia.com/>

<http://www.topozone.com/>

• My Place Fields Usage — My conventions differ depending upon whether they are U.S. locations or not. May wish to use references for standardized spelling, etc., of place names, such as the Getty Thesaurus of Geographic Names on the Internet at https://www.getty.edu/research/tools/vocabularies/tgn/index.html.

1)  My U.S. locations:

2)  My Non-U.S. locations:

There are many on-line web sites55 that discuss place names used around the world. I have interest in both British and German56 places in my lines, so have tried to collect some information on places for both of those countries. TMG has a modified UK version, and one of the Wholly Genes forums identifies mailing lists and forums dedicated to other languages and locations, such as the UK edition and the German language. With any non-U.S. location you need to decide and keep a record to help you standardize what you put in each of the TMG location fields. I prefer to keep the sovereign country in [L6], the county or state or equivalent jurisdictions recognized as subdividing the country in [L4], the city or town or equivalent incorporated entity name or recognized subdivision of [L4] such as parish in [L3], and then fit whatever else I choose to enter around those, such as a named smaller area or unincorporated village in [L2]. I include the name of the type of jurisdiction if that is common in that country (e.g. I include “county” or “shire” or “hundred” in Great Britian where it is used), but do not when it is not common (e.g. I do not put “parish” after the name of the British parish).

For places in Germany58 suggestions for the various place fields are to put the village or Stadt or city in [L3], the Kreis (county, district, or municipality) or Oberamt in [L4], the Bundesland (state or kingdom) depending on the time frame in [L5], and the country in [L6]. The country name “Germany” is usually only used after 1871 and would normally be entered in the German language as “Deutschland”.

For places in Great Britian59 I prefer to use the normal text abbreviation for a county or shire for my [L1] F2 sort code (e.g. Berks) rather than the Chapman county code (e.g. BRK) as I tend to remember the text more readily. Chapman Codes are standard three letter codes used in British genealogy for countries and counties. I do not use “UK” or “Great Britian”, or even “England” as the country in British places. Instead I put “-Great Britian” (with the single exclusion mark) in the “Country” [L6] field and use the names of the historically constituent countries of the British Isles in the “State” [L5] field - England, (Northern) Ireland, Scotland and Wales. Many choose to put those terms in the “Country” [L6] field and leave [L5] blank, but I prefer to use this data entry standard which allows them to sort and group together. English, Welsh and Scottish County names never have the word “County” attached to them, with the one exception of County Durham. Irish County names do use the word “County” before the name, e.g. County Cork. The separate word “shire” is generally considered archaic and only used as an integral part of some county names, e.g. Gloucestershire, Ayrshire. British records often include a variety of sublocations such as parish, township, city, municipal borough, municipal ward, parliamentary borough, town, ecclesiastical district, etc. You should decide and document for yourself which TMG field you will consistently use for each. I do not follow the distributed UK version of TMG Place Style60 which is Village/Area in [L3], Town/City in [L4], County/Region in [L5], and country in [L6]. Typically I choose to limit the TMG place to details such as church or small unincorporated subdivision in [L2], incorporated village/town/city in [L3], and county or shire in [L4]. What is most important is that your data entry is consistent. The citation detail or citation memo should include the entire location exactly as specified and named/spelled at the time in the source. My Great Britian place records follow the following conventions.

3)  My general place entry conventions:

• Make all entries mixed case using normal capitalization.

• Make all entries in the English equivalent form.

• Leave unknown or unused fields blank.

Some have suggested that a custom code (e.g. ‘{?}’) be entered as part of an unknown place level. That code would indicate that further research is needed to identify those place level details, and could be used as a filter for identifying such unknown data. However this increases the number of unique entries in the Master Place List (one with and one without the code). I prefer to use my *Find tags and *Assume tags to indicate needed research and data uncertainty, and either leave place level fields empty or indicate the “likely” location where the event may have occured.

• Enter common abbreviations rather than full spelling (e.g., St. Louis, Mt. Sterling).

• Do not abbreviate name modifiers (e.g., county, parish, shire). Spell them in full.

• For independent cities (e.g., Richmond, Virginia or St. Louis, Missouri), enter “-Independent City” (with exclusion marker) as the County name. But if the city is not independent, enter the county name but with an exclusion marker if the city is large and/or commonly found on maps (e.g., Jacksonville, Florida is in Duval County but is sufficiently large as to not require the county name in most output).

• Enter prepositions61 that actually define a place, like “near”, in the place field, and modify the sentence to remove the “in” or “at” that would otherwise appear. For the rules about TMG prepending a preposition for narrative output, see the location sentence variable. This convention of including the preposition in a place field defines a separate place entry in the MPL, whereas simply placing the preposition in sentences where it is used does not. Thus, “near Boston” will be a different place entry in TMG from “Boston”. Doing so also means the preposition will appear in any output of that place that doesn’t use sentences -- family group sheets, individual detail reports, box charts, pedigrees, and Second Site websites for any web page format that doesn’t use sentences. Some people choose to put the preposition in the [L1] Addressee field and use a custom style that does not put a comma after [L1]. This will also define a separate place entry in the MPL, as a place with [L1] empty is different than one that is not.

• Do NOT convert any location with a now unused name to its current name for entry in the Location field. Enter a location as it is known at the time of the event/tag, generally as it is named/spelled in the contemporary documentation for that event.62

Using the name contemporary with the event differs from some recommendations to use the currently known names. However, Version 5.0 introduced date ranges for locations and a comment field. This allows places to be left unconverted like dates, but have the ability to both specify the date range associated with this name, and identify its current name in the comment. If you have entered date ranges for this now unused location name in the Master Place List (recommended), your entry will be checked to match the date range. I make a point of using these ranges to record formation dates and information for US states and counties. You could use both a “See <currently known place>” to identify the name it is currently known, and “Previously known as <list of obsolete names>” for its previous names, in the Master Place List comments for this location. For example, Boonesborough was a town in Madison County, Kentucky, but it no longer exists (as a town). The comment could simply give directions, or specify the Latitude and Longitude, since there is no current name. Mt. Sterling, Kentucky is now in Montgomery County, Kentucky, but was in Clark County, Kentucky. Before that, it was in Bourbon County, Kentucky, and before that it was in Bourbon County, Virginia; and before that, in Fayette County, Virginia. The location should be entered as approporate for the time of the event tag, but all of these locations would have a comment referencing Mt. Sterling, Montgomery County, Kentucky. Entering as it was known at the time, these situations are made clear, and the dates and comment in the List of Places provides you the cross reference. See also the use of Location “pseudo” people in my separate Style Guide that can be used to link multiple place names to a single location. Using the [L1] F2 sort code, I could use the same code for the current location name for all these location entries. This would cause all of these seemingly different places to sort together if that would make it easier for me to find the appropriate one to use for a given event.

• Remember to identify the surety of the place.

• For most sentences, I prefer to turn off ‘at’ in locations63 and be explicit.

Surety Values.

If used, surety should be set separately on each citation for each of the five types of information (12DPM). TMG only accepts the five values noted in the table below. There are various ways to use this field, both for its intended purpose to reflect the surety of data and for customized purposes. Newer proposals have been introduced in the genealogy community for being more rigorous about reflecting your opinion of how relevant and accurate source information may be than these few values. The most common definitions of these values as intended to be used are:

A primary source may contain secondary source data (e.g., birth data on a death certificate, so the death data is primary and set to ‘3’ but the birth data may be less reliable and perhaps set to ‘2’).

For my further comments on surety and details on how some of the TMG reports control what will print based upon a threshold value for surety, and a possible non-standard use of the surety fields, see the discussion of Surety in my Source Guide. Currently I do not set surety values as I add any comments about the citation and its reliability in the Citation Memo. See also my general comments about Source Data Entry.

Special Characters

You can use the “Tools>External Utilities>Windows Character Map” facility based on a specific font to copy/paste special characters. I use Arial, as this is the default font for my TMG reports. However, there are many special characters (e.g. Unicode) which this utility can select but which cannot be saved inside TMG. TMG’s underlying software will convert such non-ANSI characters (e.g. the long ‘s’ mentioned below) to a question mark.

• Long ‘s’—One common special character often encountered in genealogy research deserves separate mention. The typeset form of the old alternative long, medial, or descending s ( ſ ), often found in older English language manuscripts, is a form of the lower-case letter ‘s’. It either has no crossbar above the baseline or only a nub to the left, while the typeset letter ‘f’ ( f )has a full crossbar. Further the cursive (script) forms of these two similarly written letters differ in the direction the descender loop turns before returning to the baseline: the modern ‘f’ turns right and up, but the alternative or long ‘s’ just turns left. If the desire is to keep the “appearence” of the original writing while only using ANSI typeset characters one could use the Florin currency symbol (Alt-159 &#402; &#x0192 &fnof;) ( ƒ ) within otherwise non-script typeset text which has a crossbar but is almost the same as the long ‘s’. But one should never use a standard lower-case ‘f’ (Alt-102). However, if your normal output is HTML a better option would be to use the defined HTML numeric code for this old typeset long ‘s’ (&#383; or &#x17F;) ( ſ ), or if the font is script use the HTML code or Unicode character for the mathematical operator integral sign (&int; or &#8747; or &#x222B;) ( ∫ ) to “emulate” the script version of this letter. (See entering non-ANSI characters below, and also the table in the Source Guide of some common HTML entity names and numeric codes for special characters and how to enter them.) However, most scholars recommend using one or two (as appropriate) modern lower-case ‘s’ characters, and not trying to reproduce this old-form long ‘s’ when transcribing such texts.

• Non-ANSI characters—While TMG’s underlying software is restricted to ANSI characters64 and does not accept many special characters (e.g. Unicode),65 TMG’s HTML marker codes can be used to specify such characters.66 If your normal TMG report destination is HTML (or you use Second Site for your normal output) entering the appropriate HTML decimal or hexidecimal code67 will display these characters correctly in a modern browser. For example : [HTML:]&#383;[:HTML] or [HTML:]&#x17F;[:HTML] when the output is HTML will produce the non-ANSI long ‘s’ character mentioned above. As noted in the embedded format codes topic, if the report destination is not HTML these HTML beginning and ending marker codes will be stripped but the entire contained text (e.g. &#383;) will output. If your word processor will handle Unicode characters, such text now could be used with a global find/replace or a macro script to convert to the actual desired character(s).

• Special Use characters—The following characters have special meaning to TMG and can cause problems in text. They generally should be escaped with the TMG backslash ‘\’ escape character to avoid their special meaning when used within text. As best I have been able to notice, there is no disadvantage to escaping them even if not needed. (See also Special Characters within tag sentences.)

If you intend to use Second Site for output, some special characters are reserved for HTML codes and can be a problem when output within Second Site web pages. See my methods of entering such characters using embedded Web format codes, entering exhibit captions, and especially the equivalent HTML codes for special characters which may be needed in entering source data.

Memos

For TMG reports I often choose to have both footnotes and endnotes, and to place source citations as endnotes, with footnotes reserved for (optional) annotations. Memos can be directly output within the narrative by including appropriate Memo variables in a tag’s sentence template. TMG will strip the leading space(s) from the beginning of an entire memo field upon data entry. Subsequent review in TMG of the field will show this change. However TMG will not affect leading space(s) at the beginning of an internal split subfield. (Second Site will strip both leading and trailing spaces of an entire memo field as well as each subfield.)

When a separate (optional) footnote of some specific text is desired, use the unsplit memo, or the first memo part of a split memo, in the appropriate tag for the annotation. Be sure that no [M] or [M1] or [M0] variables exist in the sentence to be output for that specific tag. If any other split memo variables exist in that sentence template, [M2] etc., those memo parts must be viewed by TMG as empty or the report option to output a separate memo footnote will not work. An apparent empty memo, or a memo with memo parts which output in the sentence, will not generate a separate footnote. (See the topic Empty Split Memo Parts in the “Tag Sentence Details” chapter for the placeholder character required in a split memo part to designate that it is to be treated as empty.) In the Report Definition screen for the desired report select Options, under General choose to print to a word processing file. Next, under Sources choose to print as endnotes. Then, under Memos one can optionally select separate footnotes for those memos not output in sentences. For further discussion of this special report option, see the Memo variables in my Tag Sentences chapter.

Sources

See the separate source guide (and the description of Source “pseudo” people) for my way of entering data about sources and repositories and citations to those sources.

Add Person

Need to insert comments about the Add Person template, especially the ability to have it default to a specific role68 for a tag type which is different than the first role in its Tag Type Definition. Especially need to add comments about the “add multiple” capability which was introduced in Version 8.

One thing I have tested are citations included on an Add Person template. Every tag type created as a result of entering data in the template will include all citations from the template, such as the Name tag, and any Birth, Death, etc. tag for which data is entered. If the person is added as a child or a parent, any Relationship tags will also have the citations.

For Add Multiple People note the remaining bug that Style Labels are not used on the Add Multiple People column headings. Also the bug that a Place Style of an entered location could be changed without warning.

Also need to document my customizations and usage of both the single and multiple Add templates.

Note the remaining bug if adding a Husband, Wife, or Spouse concerning no Marriage or Divorce group tag if no data in those tags.

Alternate Languages

While TMG was written based on the English language, it has the ability to enter, store data, and produce output reports in multiple alternate languages. I have not used or tested TMG multi-language features to any extent, and this book reflects that lack of experience.

It has been reported that if you choose to define a custom language, you should exit TMG immediately after doing so. Upon re-opening TMG it will fully initialize that language and only then should you use that custom language to define new sentences, roles, etc., etc. See also my discussion about Flags and their names and operations in alternate languages.

Disclaimer

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke, nor with John Cardinal, author of several TMG after-market programs. I am simply a satisfied user of these software packages and have constructed these documents to aid me in their use.

If others find these documents useful, so much the better. I do not warrant in any way that they are accurate or useful, and any use of them is at the user’s own risk.

These documents were composed with Adobe^® Framemaker 2019^® using its hyperlink and "Save as HTML" conversion features.

©MJH Consulting, 1996-2020. All rights reserved.