Michael Hannah

You are most welcome, Jim. To be able to document something that such a knowledgeable user as yourself didn't know makes me quite pleased with myself

I also use both of the two standard tags, but have customized both. I changed the sentences of the standard Immigratn tag to make the Date and the arrival Location non-optional for the immigration so if you don't include it you get the “unknown” phrases. I use the Principal role “Head” for P1, and do not use P2, and the Witness role “immigree” for all others immigrating with the “Head”. [P]<, listed as [M1],> immigrated to [L] [D]< from [M2]>< along with [R:immigree]>.< [M3]> The split tag memo [M1] optionally provides the name of the Head as listed in the immigration documentation in case it is different than any Name-Var defined for this person, [M2] optionally specifies the claimed departure location, and [M3] has optional comments. My sentence for the Witness role “immigree” is: [W]<, listed as [WM1],>< as a [WM2]> led by [P1] immigrated to [L] [D]< from [M2]>.< [WM3]> The split Witness memo [WM1] optionally provides the listed name of this immigree, [WM2] the listed relationship to the Head (e.g. “son”), and [WM3] has optional comments. The listed departure location from the main split memo [M2] is included in the immigree sentence if it has been entered. If you create ship “pseudo” people in your dataset, you could also add the ship as a witness with custom role of “ship” and an appropriate sentence. I changed the sentences of the standard tag Emigration in a similar manner to require the Date and the Location from which the emigration is taking place, with equivalent “emigrated from”sentences and the Witness role “emigree”, Hope this gives you ideas.

As Jim suggested, many of us have a separate Project that we have created where we run tests. From previous tests that I have run, a Max Surety is computed for each category [12DPM] based on the highest surety value in any source citation for that category that has been entered for a particular tag, whether the citation has been excluded or not. If the tag prints, the printing of a citation is then based only on whether it is an excluded citation, not on its surety. If the surety threshold has been set, and the Max Surety for all categories is less than the threshold, the entire tag and its citations will not be printed. However, if some category meets the threshold but other categories do not, then the event will print but those categories that do not meet the threshold will not print. For example if the Max Surety for Principal1 meets the threshold but Date and Place do not, the tag will print with the Principal1’s name, but the sentence will operate as if the Date and Place were blank, i.e. if they are non-optional sentence variables they will produce the “unknown” text. So in your case, if you have the Surety threshold set to one, the tag will print and the Principal1's name will print, but the Date will operate as if blank. Hope this helps,

As Virginia pointed out, Version 6 has added considerable flexibility to the TMG views by providing a way to customize multiple versions of layouts. Earlier she mentioned Terry's Tips, and I would recommend http://tmg.reigelridge.com/layouts.htm as it describes the Version 6 layouts. While Version 6 now allows other subwindows (e.g. flags, Focus Group, etc.) to also share screen space with your FGS type Family View, if you want to almost duplicate the old Version 4 view, you can. Select the Family View for the Details subwindow, close any other subwindows, and from the "Window" menu item be sure that the Children subwindow is also selected along with Details. Now move and/or resize the Details to cover the top half of the TMG window, and the Children to cover the bottom half, resizing the columns in the Children subwindow to your preferences. Then save this custom layout with a name of your choice as described in Terry's Tips. Whenever you want this view, you can now select your custom layout from the "View >> Layouts" menu. Hope this gives you ideas,

The three "views" only change what you see in the "Details" window for a given layout. Person view gives you the primary parents in a subwindow with the primary name, and then the tags. Tree view will give you multiple generations, with no extra information about the ancestors. Family view will give you person, their "currently viewed spouse", and the two sets of primary parents, with BMD information for these six people, and only a count of the children. Any other windows, like Siblings, Children, Flags, etc. are dependent upon what other windows you chose to include in this layout and do not change or disappear by selecting a different "view". Under the main menu item "Window" click to turn on or off any of these other windows, arrange them as you wish, and then save this layout with an appropriate name. Now that layout can have whatever other windows you want, like Children, and the Details window can be whichever of the three views you want.

But, Jim, I don't understand. I don't see the need for these extra steps in order to get the List of Tasks report to show the Principals for a task linked only to an event. Further, you can only link to one person, whereas the task can have two Principals. My tasks are only linked to events, I have never linked to a person. When I edit any of my tasks it shows Event assigned, and Person, Source, and Repository "Not assigned yet". Even in the Research Log itself, when you highlight a task the "Subject" it displays is the event ID and name followed by the Principals, and when you edit the task the Principals are listed following the Event assigned. In the Person View of a person, if I click on the Research Log icon it lists all the tasks that are assigned only to events but for which this person is a Principal for those events. I don't find a circumstance where the Principals are not listed. So I still don't understand Joan's problem.

Joan, I cannot duplicate your situation. All of my tasks are assigned only to events and my List of Tasks report outputs the Principals that are set for that event tag. What are your options for your List of Tasks report set to? As an example, I have my "Sort By" tab set to "Task Name" and the "Names" tab set to "Surname caps" and "ID Number". When I set the Subject of the report to "All Tasks" and print to screen each task gives the Task Name on the first line. It then prints the Tag Type name on the second line followed by the tag date if there is one, then the names of the Principals with their surnames capitalized and their ID number, and finally the location entered into the tag. Do you not see this? Are you looking for names of Witnesses to your event tags? These do not show on the List of Tasks.

Of course, if you simply want people associated with a certain type of event in that city or state, you could have something like Birth Group... City Contains [?] END

You might get close with a List of Sources with a filter for all the source element groups that appear on the Source Definition General Tab that are empty. The non-people source element groups are: Title, Short Title, Subtitle, Short Subtitle, Record Type, Date, Second Date, Location, Second Location, Publisher, Publisher Location, Series, Edition, Version, Volumes, Pages, File Reference, Record Number, Film Number. For example: Title Is Empty ORShort Title Is Empty ORSubtitle Is Empty OR... The "people" source element groups (Author, Subject, Compiler, Editor, Second Person) are specified slightly differently: Author-ID... Is Empty ORSubject-ID... Is Empty OR... There is a maximum number of filter lines for a single filter, so you may have to run multiple reports to check all source elements. Of course, for a given source a particular element may not even be defined, so you will be listing those when you do not need to, so this may lessen the value of such a report. It would probably be more useful to restrict the report to a particular type of source and only check for the source element groups that you have defined for that source type, e.g. Source Type is Census, Federal (Filmed) AND( Title Is Empty OR Short Title Is Empty OR Subtitle Is Empty OR ... ) END Hope this gives you ideas.

A more complex filter for a List of People that would find people with missing "-bio" parents but had some kind of parent relationship tag might be: Mother* Is Known ANDMother-Bio... ParentID = Equals 0 END just in case you have some that are not "-fst" but something else.

Clever idea, Teresa, and useful for a lot of purposes. For other workarounds, you could simply write a custom main tag sentence and/or memo to say exactly what you want. Of course Teresa's idea will automatically let the special information show associated with the Witness name in the main tag sentence. I usually don't put these details in the main tag sentence, but reserve these details to only print in the Witness sentences and use split Witness memos and appropriate Witness sentence structures. Thus that Witness person's sentences mention other information unique to them, like their location, age, etc. I could see this wish adding extreme complexity to the main tag sentences, especially if multiple people are assigned to a generic Witness role or to a custom role. What would you have [W] or [WO] produce, especially if all or part of the location and/or age were missing/not computable? Or a whole new set of [Wx] variables like [WL] for names and locations, [WA] for names and ages, [WAL] for names and ages and locations in that order, and matching [WOL] etc. ...???? I have often thought it might be nice if the Witness memos, including the split Witness memo parts, could be referenced in the main tag sentence, as a more generic solution to this wish. But I could not get my mind around the complexities to even figure out how to propose a solution, especially in the light of multiple people assigned the same role, each with their unique Witness memo. If I were Bob, I would probably file this wish in the "too hard to even figure out how to do" folder, but then Bob has surprised us with features that I previously thought were too hard to do, so you never know. At least there ARE workaround ways to output what you want with the current software, just not as easy or quite as automated as your wish might imply.

For surnames with various spellings, some have chosen to add a non-primary custom tag in the Name group (e.g. NameStand) for every person whose primary name tag is a different spelling. Adding this tag identifies the standard spelling of the surname that they choose to use in their database. By having this custom name tag, all such people in the database will sort within that standard surname in lists like the Project Explorer as long as you do not limit the list to primary names only. Of course, since it is a separately named tag you can selectively choose whether to include it in various reports. Another method I have heard about is to create a custom tag in the Other group (e.g. Surname) with P1 this individual and P2 a "pseudo" person entered into the database. This "pseudo" surname person would have their primary NameVar tag with just the surname and a suffix of "SURNAME". This "person" could then have tags, such as all the various NameVars for that surname, and documentation about that surname, linked in this single place to document all the information you have found about this surname and its variations. The Details view of this person will also show all the people you have linked via the custom tag, and if you use the "real" person's birth as the date for the tag they will show in chronological order. Of course, since it is a separately named tag you can selectively choose whether to include it in various reports. And if you use a flag to distinguish this person as "pseudo" from "normal" people, you can choose whether to include this person in various reports. Hope this gives you ideas,

Yes, you can use square brackets so long as you realize that TMG can become confused if the contents within the brackets is the same as a defined variable. Your example of "[on-line database]" is fine, but adding something like "[comments]" would not since this word is a variable.

Hello John, Welcome to a great genealogy software package. If you would like "yet another" way to enter census data from yet another user you might consider the following. I have two general types of custom census tags, one for enumerations and one for index or soundex records. The general format of my custom census tags has the Head of Household as Principal1 and a census "pseudo" person as Principal2. I have only three roles, one for a spouse, one that is used for all children, and one that is used for all other enumerated individuals in the household. Rather than have multiple roles for different relationships I enter the relationship as a split witness memo element. Finally, each of the two types has three subtypes, one for the actual recorded information, one as a "placeholder" to indicate that I need to find the census record but pre-linked to everyone expected, and one to record that a specific census record does not exist for that household in that place. This gives me six custom tag types: CensusEnum, CensusFind, CensusNil, CensusX, CensusXFind, CensusXNil. Examples of my naming conventions for census "pseudo" people: Given=1920 Census Surname=USA, Ohio, Washington County Suffix=EDs 100-124 Given=1920 Census Soundex Surname=USA, Ohio Suffix=R263-S142 A census for a location is linked as Son-Oth with a Father census person for the next larger locale. The mother of the census person is a location "pseudo" person for this location. Rather than including a long discussion of my custom tags in this posting, you can probably guess how I use them, and what goes in each part of both the main and witness split memos, from the sentences for the two main tag types of CensusEnum and CensusX. CensusEnum sentences (which has a transcription of this entry attached to the tag as a text exhibit) Role=Head (Principal1) Male: "[M1] was enumerated in the [P2G] in [L] as head of household." Female: "[M1] was enumerated in the [P2G] in [L] as head of household." Role=Extract (Principal2) "[:CR:][:CR:][bOLD:][P2F] Census Enumeration[:BOLD] of the household of [bOLD:][M1][:BOLD] in [L] linked to [P1]" Role=spouse Male: "The [P2G] in [L] enumerated [WM1] in [P1S] household as her husband" Female: "The [P2G] in [L] enumerated [WM1] in [P1S] household as his wife" Role=child "The [P2G] in [L] enumerated [WM1] as [WM3] in the household of [P1]." Role=Witness "The [P2G] in [L] enumerated [WM1] in the household of [P1]." Role=spouseAssumed (used if the relationship is not explicitly documented in the entry, or if the entry does not include the person's name) Male: "The [P2G] in [L] enumerated [WM1] in [P1S] household, presumably her husband" Female: "The [P2G] in [L] enumerated [WM1] in [P1S] household, presumably his wife" Role=childAssumed (used if the relationship is not explicitly documented in the entry, or if the entry does not include the person's name) "The [P2G] in [L] enumerated [WM1] presumably as a child of head of household [P1] " Role=assumed (used if a relationship is not explicitly documented in the entry, or if the entry does not include the person's name) "[W] is assumed to be [WM1] who was enumerated in the [P2G] in [L] in the household of [P1]" ============================================ CensusX sentences Role=Head(Principal1 if other members of the household are listed with this index entry) Male: "The [P2] cites the household of [M2] in [L] as [M1]" Female: "The [P2] cites the household of [M2] in [L] as [M1]" Role=Alone(Principal1 if this individual is indexed separately from the household. No witnesses would be linked to a tag using this Principal1 role) Male: "The [P2] separately indexed [M4] in the household of [M2] in [L] as [M1]." Female: "The [P2] indexed [M4] in the household of [M2] in [L] as [M1]." Role=Extract(Principal2 if transcription attached as an exhibit) "[:CR:][:CR:][bOLD:][P2G][:BOLD] entry of the household of [bOLD:][M2][:BOLD] in [L] linked to [P1]" Role=Source(Principal2 if there is no transcription attached) "[:CR:][:CR:][bOLD:][P2G][:BOLD] entry of the household of [bOLD:][M2][:BOLD] in [L] linked to [P1]" Role=spouse Male: "The [P2] listed husband [WM1] in [P1S] household index entry in [L] cited as [M1]." Female: "The [P2] listed wife [WM1] in [P1S] household index entry in [L] cited as [M1]." Role=child "The [P2] listed [WM1] as [WM3] in the household index entry of [P1] in [L] cited as [M1]." Role=Witness "The [P2] listed [WM1], indexed in the household of [P1] in [L] cited as [M1]." Role=spouseAssumed (used if the relationship is not explicitly documented in the entry, or if the entry does not include the person's name) Male: "The [P2] listed [WM1] presumably [P1S] husband in her household index entry in [L] cited as [M1]." Female: "The [P2] listed [WM1] presumably [P1S] wife in his household index in [L] cited as [M1]." Role=childAssumed (used if the relationship is not explicitly documented in the entry, or if the entry does not include the person's name) "The [P2] listed [WM1], presumably as a child of head of household [P1] in [L] cited as [M1]." Role=assumed (used if a relationship is not explicitly documented in the entry, or if the entry does not include the person's name) "The [P2] is assumed to list [WM1], indexed in the household of [P1] in [L] cited as [M1]." ============================================ Hope this gives you ideas,

Need more information for ordinary users like myself to answer your question. Is there anything in common about when the parents are included and when they are not? Which sentence have them and which do not? Is it dependent upon the tag type, e.g. Marriage has them but Birth does not, or...? Do all the sentences where you expect the parents to be included have some variation of the [PAR] sentence variable? Do the spouses that do not show parents have a set of parents that are marked primary? Happy to try to help , but need more information.

Whether TMG can calculate an age is dependent upon what is entered as the date (not sort date) in both the primary tag in the Birth group and the tag with the age variable in the sentence. There has been much discussion on this calculation, and TMG even changed the behavior of [A] for version 6.02 only, but reverted in 6.03 to the following behavior. The [A] variable produces output in years only when both the primary tag in the Birth group and the tag that contains the [A] variable contain the full (day, month, year) dates, and the age is over one year. In your case Thomas has an age of less than one year, so there is no output. If either date has an appended question mark, then the age will have an appended question mark. It returns no value when the age can not be precisely calculated (e.g. incomplete dates that have only the year). If the [A] is bound by conditional brackets “” then the sentence variable is ignored for incomplete dates or an age under one year and no age is output. An unconditional use of the variable will return “at an unknown age” for incomplete dates. The [AE] variable will produce an exact age (years, months, and days) if both dates are complete. It will still produce output even if only approximate dates are known, but it will be only years. The TMG documentation calls [AE] an exact age variable, I choose to call it an exact or estimated age variable. There is currently no variable to always output just years regardless of the completeness of the dates. You are not alone in finding these age sentence variables confusing. Hope this helps.

Sorry, Dirk, Some time ago the seasoned user Paul E. Lawrence posted the following about what font setting in Preferences>Program Options controls what display font. At that time he also noted: “I don't find any setting which affects the Simple Pick List.” Data Entry -- Minimum memo font size, Maximum memo font size -- Affects memo field only, and the expanded memo window Lists -- Minimum font size, Maximum font size -- Affects all lists which include: Details Window (Personal View only), Children Window, Sibling Window, Flag Window, Master Source List, Master Repository List, Master Place List, Master Event List, Master Tag Type List, Master Style List, Source Type List, Source Elements List, and in the Tag Entry Window: Witness list and Citation List Project Explorer -- Font Size -- Project Explorer, Expanded Pick List, Focus Group, Preference List Other -- Family View font size -- Family View Window Other -- Tree View font size -- Tree View Window So it would seem that you can set the font for the Expanded Pick List, but not the Simple Pick List. It would seem that the Simple Pick List should be controlled by the "Project Explorer" setting, to match the Expanded Pick List, but is not currently available.

The Double Exclusion Marker is documented in HELP under the topic "Exclude Information". The HELP entry states: "The Full footnote, Short footnote, and Bibliography template fields on the Output form tab of the Source Definition screen also support the double exclusion marker. A template so marked does not show when previewed nor does it print." A custom Source Type that has a Bibliography template with Source Elements but whose Full footnote, and Short footnote templates consist of only the Double Exclusion Marker DOES print. You get both a footnote reference printed in the text, and you get a footnote entry printed, although the entry consists of only the reference number and a period. Based on the HELP documentation, I believe no footnote reference should print, nor should any footnote entry be printed, but a bibliography entry should still be generated. If the Double Exclusion Marker worked as I believe it is documented, a custom Source Type with such templates would provide the way to generate a bibliography entry without a footnote, as has been requested previously on this forum.

No, Bibliography entries do not have numbers, and do not have linkage references to the text since multiple references to the same source collapse into a single bibliographic entry. Only footnotes/endnotes have numbers in the text and in the footnote/endnote. With both the Full Footnote and Short Footnote having double exclusion, there is no need for any numbers of any kind, either in the text or in an otherwise empty footnote/endnote. There is no need for (or desire for) a place holder. The documentation says that a double exclusion will cause the specified template not to print. Well, that is exactly what I want to have happen for those two templates: no number, no footnote/endnote, no "place holder", no printing of anything related to that template.

As a "wish" item I would like to see embedded source citations resolve two minor problems: 1) defining embedded citation detail as excluded when the Source Number is omitted is not possible, 2) embedded citation detail that begins with a number when the Source Number is intended to be omitted either considers that number as a Source Number or produces an error. Embedded Source Citations are documented in HELP under the topics "Memo" and "Citation" and specifies that various parts of the [CIT:]num:surety;detail[:CIT] construct are optional. "The colon and surety value may be omitted..." [CIT:]num;detail[:CIT] "The semicolon and citation detail may also be omitted..." [CIT:]num:surety[:CIT] or [CIT:]num[:CIT] "Finally, the Source Number may be omitted...and no entry will be made to the bibliography." [CIT:]detail[:CIT] It is the last optional construct that causes problems. The documentation does not mention using an exclusion marker for embedded citations, but if a Source Number is included and is preceeded with a single exclusion marker (a dash) it functions as an excluded citation whose printing is controlled by the report option. This is a useful undocumented feature and should remain. However, omitting the Source Number and beginning the citation detail with a dash does NOT cause the citation to function as an excluded citation, the dash is printed as part of the citation detail. As has been previously noted by users, intending to omit the Source Number but having an embedded citation detail that begins with a number causes TMG to either consider that number as a Source Number and discard the citation detail or if the number does not match an existing Source Number produces an error. Further, omitting the Source Number but beginning the citation detail with ':;' (colon semicolon) or just ';' (semicolon) in an attempt to inform TMG that the Source Number and/or surety value is omitted does not work. The leading special characters are printed as part of the citation detail. My proposal is that Embedded Source Citations recognize two special leading constructs as an indication that the Source Number has been omitted: 1) a leading semicolon [CIT:];detail[:CIT] and 2) a leading single exclusion marker followed immediately by a semicolon [CIT:]-;detail[:CIT] The first should trigger that the Source Number and surety are missing, strip the semicolon, and accept whatever follows as the citation detail. This would fix the leading number problem. The second would do the same and strip both the dash and the semicolon but also trigger this citation as an excluded citation whose printing is controlled by the report option. In my opinion these two constructs would resolve existing problems and make it easier to use Embedded Source Citations when you wish to omit the Source Number.

Mark, Jan made an excellent suggestion that will work for linking locations in Second Site to some master location. However you seem to want footnotes/endnotes linked to a place-name in a narrative to refer to a separate narrative about the location and all its place-names. I think my proposal for location "pseudo" people will accomplish this, but my method for producing the footnote/endnote described above is not correct. That method produces a footnote/endnote in the narrative of the location pseudo person, not in the main narrative. I think the following will do what you want. For example, if a Hans Schmidt was born in Ost-Berlin and you want a footnote/endnote in his Birth tag sentence to refer to your discussion of Berlin, you could do that with the following custom sentence in the BIRTH tag of Hans. You would put the old place-name (Ost-Berlin) as the location for the tag, and would link the location pseudo person (Berlin) as a Witness using the custom role of "Location". Now modify the sentence in the BIRTH tag for Hans to have an embedded citation: [P] was born [L][CIT:]For details about [L] see the report on [R+:Location].[:CIT] You could add this Witness and embedded citation to any tag sentence where you wanted this reference. While the embedded citation can be added to a "local" version of the tag, roles must first be defined as possible in the "global" definition of a tag type. Hope this gives you ideas

By the Exhibit "Abbreviation" field I presume you mean the Exhibit "Topic" field, and its length is short. For this reason I have chosen to put the source abbreviation from which this is a text exhibit in the "Caption" field, but that may not work for you for non-text exhibits. The only other option is the Exhibit "Description" field, but I have yet to find a way to access the exhibit description for printing within TMG, so its use is limited. I share your frustration over the short Caption field

I don't know of a way in TMG to do this other than the pseudo location person method I mentioned (although maybe I am just not creative enough to think of a different way). A pseudo location person for each city could have custom tags for the history of the city-name, exhibits of the coat of arms and maps, a tag for a description of the city, Name-Var tags assigned date ranges for the historical names of the location, and any of these tags could have source citations. You could link any tag for "normal" people to this pseudo person by making the pseudo person a Witness to that tag, possibly by defining a custom role of "Location". A custom sentence for that role might be just the two exclusion marks "--" to prevent a sentence in the text of the report, but the Witness memo might be "For further information about this location, see the separate report for Berlin". That would cause the memo to print as a footnote/endnote since it is not included in the sentence. You could have as many of these pseudo location people for as many cities as you wish. If you define a custom flag (perhaps named PSEUDO) with different values (perhaps N=normal, L=location) then you could produce reports that filtered on that flag and include or exclude such pseudo location people from the report. For example you could produce a report that was nothing but these pseudo location people for an appendix to some other report. Hope this gives you ideas as you think "one step further",

Previously others have suggested a custom source type where the FF and SS templates consist of only two dashes (the double exclusion mark), and then cite this. Unfortunately, this still produces a numbered footnote or endnote citation, but the citation consists of only a period, which some of us consider to be a bug. However, that is how the program currently works. In my opinion, a custom source type like this is precisely how one "should" be able to do this in TMG, but you can't with the current version. I agree with your wish, and hope that a future version of TMG will deal appropriately with such a source type. The only method I have seen to have a larger bibliography than the non-excluded citations requires a "trick" using what are often called "pseudo" people in the dataset. For various reasons some prefer to have multiple projects and datasets, but desire to have some or all of the sources available in the Master Source List of every dataset and project whether they are (yet) cited on a tag in that dataset or not. The trick is to have a "pseudo" person in the dataset that has a special tag where you have cited once every source you want in the Master Source List, then export and merge that person as needed. (You might also choose for this "person" to have one each of every custom tag type for ease in exporting those.) Usually the dataset has a custom flag with a value to indicate this is a "pseudo" person so that filtering on the flag will exclude this "person" from "normal" reports, etc. If you create such a "person" and cite every source that you want in the bibliography on one of its tags, you can print a report of just that one person. That produces a "master" bibliography. Next print your "normal" report, excluding and keeping citations with endnotes/footnotes as you desire and print that report. Now just replace the bibliography from that report with the "master" bibliography. Takes a little bit of time to set up, i.e. citing once each source on that one tag that you want in the bibliography, and remembering to add new sources to this "person" as well, but this might do what you want. Hope this gives you ideas,

Hello, No apologies necessary for your text. Your English is much better than my German. A place is a single entry in the Master Place List (MPL) made up of the ten place fields that are combined together for output based on the one place style associated with that place entry. The place text is not stored with a tag. Instead, the tag actually references a place entry in the MPL. If you change an MPL entry, all tags referencing this place entry will change their output. Many different names for the same location can be stored in the MPL. However, an event tag (such as BIRTH) can only link to one location entry in the MPL. You must choose your own non-standard method to refer to other names a location may have had at different times, or other spellings the location may have in this or other languages. Like many users, I do not link event tags to the MPL entry of the current name for a location if that location was known at the time of the event by a now unused name. I link to the MPL entry of the location as it is spelled and specified in the documentation of the event. As of Version 5.0 TMG introduced date ranges for locations and a comment field. (See Start and End Dates in the TMG Help under Edit Place.) This allows MPL place entries to be recorded as they show in documentation, as well as provides the ability to both specify the date range associated with this name, and a way to identify its current name. If you enter a date range for a location name in the MPL, every time you link an event tag to that MPL entry TMG will be check that the event date is within that location's date range. Every MPL entry also has a comment field. You could enter some text like: "See " to identify the place by the name it is currently known. You could also enter text like: "Previously known as " in the comment field of the MPL entry of the current location name. A List of Places report in TMG will show these date and comment fields and provide the cross reference. I have seen two ways to deal with multiple names for the same location in reports, and there may be others. Perhaps you will discover a method that others may wish to hear about. These two methods are: unusual use of place fields combined with place styles, and location "pseudo" people. Unusual use of place fields If you do not use every one of the ten place fields for data (for example many users do not use [L10]) you can store the full "current" location name in that one unused location field. (There is a maximum of 99 characters for a location field.) Since Place Styles can define which of the 10 fields will output, whether this field will print can be determined by what place style is used. What you put in that unused field will depend upon how you define the Place Style, and/or how you define your output. For example, an event tag sentence might include text like: "" This method is not greatly non-standard. An advantage of this method is that all ten fields are displayed when you open an event tag linked to that place entry, which reminds you of the current name. Location "pseudo" people Much more non-standard are location "pseudo" people. TMG is a very general purpose relational database program. Therefore, a TMG "person" entry can be thought of more generically as a "XYZ" entry with a name/label, tags that describe possibly dated information or events about an XYZ, the ability to link (relate) XYZs directly or via events to other XYZs and people, and the ability to generate reports about XYZs. If you can force yourself to ignore that TMG labels the XYZ entry a "person" and that it labels the links to other entries as "children", "parents", and "witnesses", then the possible uses of TMG "person" entries, tags, and relationships is limited only by your own imagination. Since this is an unusual use of the "person" entry in a TMG dataset, for each such "person" I add a tag to that "person" (I use a custom "Created" tag type in the Birth group) to explain why this pseudo person was created. I choose to also have a custom PSEUDO flag with a value that indicates not only that this is a "pseudo" person but also what kind, so I can filter for these non-standard "persons" and easily exclude them from reports. I also set a special background color accent based on this flag to visually distinguish entries and tags associated with pseudo persons. As the "names" of these "people" are likely contrived, a special naming scheme usually needs to be defined. Further, the Sort names can be defined to avoid having these "people" sort among "normal" people. You can manually prepend both their SortGiven and SortSurname with some special character (in the past I used a '+' plus sign). I believe a better alternative is to use the Name Styles feature, and define a special name style for each type of pseudo people. This feature allows you to define prepended special characters as part of the Sort names. I define a Location "pseudo" person to link together multiple "place entries" in the MPL that actually refer to the same location. I use multiple Name-Var tags for this "person" with date ranges to reflect when the location was known by each name. TMG Name indices link all these name variations to this one "person". The primary name for this "person" is the Name-Var that is the “current” name. If an event tag links to an MPL entry that refers to this location, I also link the location "person" as a witness (possibly using a custom Role) using the primary "current" name with a witness sentence of "This location is currently named [W]". If a larger area was identified by a single name for a period of time and then subdivided, the larger area "person" could be the "mother" of the multiple subdivided "daughters" who were created/born at the time of the subdivision. Using Location "pseudo" people is more complex, is more non-standard, and takes some effort to set up. However, I have found it useful for dealing with locations that change their name over time. I hope this gives you ideas,