Peter Tarkkonen
-
Content count
153 -
Joined
-
Last visited
Posts posted by Peter Tarkkonen
-
-
One Journal report started to give some haedache.
This is a report which has been working a week ago and nothing has been changed on report itself. Several people has been added.
After running some time (maybe 25% out of 500 people) an error "String is too long to fit, 893 reportobj.membed" shows up. Only way out is to abort report.
After that closing TMG causes an other error ie. "Unknown member roprotectionman". This will show up few times before TMG closes.
Tested with other Journal report. Worked fine.
Pages created with Second Site works fine.
Reindex, Optimize and Validation all go thru fine and do not report any problems.
Restarting PC (Vista) does not help.
Now I am worried if some data used by this one report has been corrupted.
Any ideas?
Peter
-
Export/import procedure only import "translated strings", not whole file?Right. Only the language(s) that you are working with.
The point of allowing the update replacement of the language files is to get all of the changes coming from Wholly Genes when the program is updated and the language file is updated. The English part is updated by the programmers as the program changes. The translations for the other standard languages are constantly updated by the various translators. You want to get those changes each program update.
And use the export/import procedure to maintain your personal changes (for whatever language you are customizing).
Thank you!!
You just made my day!
Peter
-
Peter,The standard procedure is to export your custom language before installing the program update. Then the language file can be updated when the program is updated. After the program update, you import your custom language and can then translate the added strings.
The reason for using this procedure is that if you had an installer option to update the language file or retain the current language file, you would not get the new strings in the language file if you chose to retain the current file. That's why the export/import procedure is required.
Terry has some articles on his site regarding using custom languages.
http://tmg.reigelridge.com/Language.htm
Jim
Jim,
just want to be sure I understand this right.
Export/import procedure only import "translated strings", not whole file?
Peter
-
Peter,I don't know. It would be nice if there was a way to keep our old ones and compare so that we could decide which to keep and which to update. In the meantime, would a file in a word processor help. You could have two columns, one for the words and another for what you changed them too. THen you could compare them once you upgrade. Since I use English two, I just exported my file out, and after the update, I import it back in, but that might not work for a language that's being translated.
Hi!
Even a Word file would work with me because I have not translated too much, only phrases needed in Journal report. Ofcause it would help if this Word file includes only those lines which really has some translation. This would keep the list much shorter.
If I have undertood correctly, by importing translation back, you replace existing translation file with old one. And that would mean that some words/phrases needed by new revision does not exists at all?
Peter
-
TMG has a very powerfull tool; Lauguages. This is most probably needed by those who live in different language area than those which come with TMG.
With this possibility it is easy to create new language and translate several phrases etc. used f.ex in Journal report.
However, whenever new upgrade is installed, one has to think should I use new language file or keep the old one which has allready been translated. I any case once and a while latest translate file should to be taken in use.
Now to minor problem which this "upgrading" generates. By this upgrade all translations will be deleted (overrun) and language has to be recreated and all translations has to be entered again.
I do not personally have too many translation which I have done, maybe only 100, but I have to remember them because old files do not exists anymore.
Is there a possibility to scroll thru exported language file or maybe print changes made. If only I could print those lines which were translated, at least I could live with it.
Peter
-
Mike&Mike,
thank you for your kind help! I have realized that an easy answer does not exist.
After considering different options I have decided to stick in my earlier way of doing (as long as possible) ie. one physical location has only one record in database.
Peter
PS. To me Detail is house with a number (or street address including house number), City is Village, County is City and State is province etc.
Peter:I think I see your problem. You wish to have the house address as part of the location. If you have 50 houses then you would have to have 50 locations, New 1, New 2, New 3... Then if the village changes name you have to have 50 more locations. If you had 200 houses the numbers increase dramatically.
I think what you are looking for is a location template sentence structure which would have something like:
<[Addressee], ><[Detail], ><[City] [M],> ...
Where you could put the actual number in the memo field for the tag and New York in the City field of the location. This way you could construct the address for any house in the village and when the village name changes you would have just a second location. Unfortunately TMG does not allow the [M] or any other variable in a style template other than those given in the style.
But what about this:
Have a place style which only has Addressee, Detail, and Village in the template. That is the template sentence ends with the name of the village.
Make a role for each event, birth, death, marriage, etc. which needs the house number and then set the associated sentence for that role to handle the address. For instance:
For Birth have a role named House-Number and the sentence could be:
[P] was born <[D]> <[L]>< [M]>
If you need additional data in the location such as parish or province or ... (I am not familiar with jursidictions in Finland) then rearrange the location style to something like:
<[Addressee], ><[Detail], >< [Province], ><in the house numbered [Village]>
Then the role sentence would work. However this would be a kludge on the address part of the sentence and may not be acceptable.
Hope this helps.
Mike (also)
-
Mike,
I fully respect the work, values and assumptions of TMG makers. However I am sure there is allways room for new ideas and ways of seeing things. TMG makers will then decide what they will do and what not.
I see this the same way as different names of individuals. There is no dublicate people, just name variations. There is many who can handle this in TMG. In different events you can control name of an individual. Absolutelly clever!
It is not just one place which have dublication.
We used to call houses of a village with numbers like New York 1, New York 2 etc. up to 50 in some cases. This was a practise which identified very detailed location, like a street address with a number today.
Then one day this village changed name to Old York and same time all houses had new names like Old York 1, Old York 2 etc. And during history several villages has changed names.
This will increase and has increased number of place records a lot. This is one drawback.
Peter
Thank you for your ideas.It looks that I was right when I assumed that there is no easy answer if I want to have just one place record.
However, would it be great to have just one place record which has several "names" depending time an event took place.
New York (1700-1750)
Old York (1751-1900)
And if event took place on 1730, New York would print out etc.
Peter
You might think it would be great to have TMG smart enough to be able to pick an appropriate "name" for a place depending upon the date of the event, but I believe previous comments have shown that this would be counter to basic principles of the TMG authors. First, many users believe the place name should show what is documented concerning that event, even if that place name might differ from other documentation sources and might even differ from what would "automatically" be chosen based on the date. Second, the TMG authors seem to have a strong aversion to having the software automatically make assumptions concerning your data. I don't think they would want the software to "assume" that the place name was one of many names based on a date. They seem to want to be sure that you can choose to have the place name what you want, and it be your decision. Personally I am glad they have this aversion to the software making assumptions, and I hope they stick to those principles.
You seem to want to avoid multiple place names in TMG's Master Place List for the same physical location. I personally don't see this as a problem, why do you?
As for a date limited place name, do you realize that you can specify a date range for a place entry in the MPL? Then you can set your Preferences to warn you whenever you select that place name for an event whose date is outside that range. Thus TMG can help you be sure to select a place name appropriate to a date, but will not do so automatically.
Just my observations.
-
Thank you for your ideas.
It looks that I was right when I assumed that there is no easy answer if I want to have just one place record.
However, would it be great to have just one place record which has several "names" depending time an event took place.
New York (1700-1750)
Old York (1751-1900)
And if event took place on 1730, New York would print out etc.
Peter
For your example I do end up with three locations:New York
Old York
New York (now Old York)
Virginia and West Virginia is a real example.
It gets really exciting when you have counties that are in both states and those counties have also changed over the years such as in Virginia and then in West Virginia. For fun try to track the changes in Tennessee or Idaho, especially prior to statehood.
I also use custom styles to enable some identification in the Master Place List as to which of the three (or more) variations I am using. L9 (LatLong) becomes 'Time Span' and L10 (Temple) becomes 'Jurisdiction'. Since I need to put a to time in the time span which does not have to be changed as I get older I use 2200. I also use the Start Year and End Year fields to help me when entering a new tag. And I put some description of the change(s) in the comment box. This adds another level of complexity to entering data but it does work for me AS LONG AS I PAY ATTENTION to what I am doing.
So for example using the Virginia and West Virginia example I have
Virginia 1776-2200 State-US 1776 2200 Formed from the colony of Virginia becoming the 10th state in 1788.
Virginia (now West Virginia) 1776-1863 State-US 1776 2200 That portion of Virginia which formed the state of West Virginia in 1863.
West Virginia 1863-2200 State-US 1863 2200 Formed from the state of Virginia, becoming the 35th state in 1863.
With counties it gets even more chaotic in some cases. For example my wife has ancestors who went to Augusta County, Virginia, prior to 1775. The successive generations in the same area were in Botetourt, Fincastle, Montgomery, and finally Wythe Counties.
And somebody will probably bring up the changes in the European nations over the last 500 years. To sum it up in one word, UGH, ain't politics fun??? In order to keep track of all these changes for the US you need something along the order of The Red Book or AniMap software.
Have fun. I will be the first to admit it is confusing and you need to keep focused on the situation as it can easily be compromised by inattention to the details related to the history of the location. But that is what makes for an interesting challenge and also adds a little bit of interest into the otherwise boring list of people.
Mike
-
During history some locations (=places) have different name. This is very common in house names but also some cities and villages have changed name, even several times.
Let say between 1700-1800 a place was called New York and after 1801 it was called Old York. Ofcause all events happened in same physical place but in all outputs it should show that events between 1700-1800 took place in New York and after 1801 in Old York.
Easy solution would be to add 2 or more different places and then use which ever is appropriate.
However, is there any other possibility if I do not want to add "a dublicate" ?
Good ideas please.
Peter
-
Mike/Terry,
thank you again.
Yes, I have Second Site and it is a great product, but I have not started to use it for publishing yet.
Translation to Finnish is quite complicated job. It is not just to translate word by word, but also whole structure of language is different. Also some sentences are allready translated in TMG and mixture looks quite odd, actually my first tries did look quite ugly.
I will make it work, but meanwhile I have to live with Journal (HTML) report. Also, Journal is printable, some eldery relatives get it printed from web and they love it.
Also bigger picture is easier to see from Journal.
I have studied fully descendants of 11 ancestors of mine (including all who carry that surname). To publish these studies from ancestor down, Journal is a great report.
It is great to see that there is allways help available. Thank You fellows!
Peter
-
Peter,To expand on a comment I made above, I believe that the issue of "standard" tags is primarily a problem only in predefined printed reports. In my opinion, in the modern world these are being replaced by web reports, such as can be produced by the program Second Site. I believe the problems with the legacy printed reports are caused by the fixed (and often convoluted) method required to define and document linkages to the narratives of people in such reports. These reports have created ways that work well in leafing
forward and backward through the printed pages for the limited set of "traditional" family structure linkages, but as you point out they have problems with "non-traditional" linkages and family structures.In contrast, "web" reports have no such problems thanks to the hyperlink.
Any two people related to each other in any manner, whether "traditional" or "non-traditional", can have their names in both narratives mutually hyperlinked to each other's narrative. Thus navigating forwards and backwards through any kind of relationship is a simple click. There is no need for fixed output structures or numbering schemes based on only a limited set of linkage mechanisms to get from one person's narrative to another's. Further, it becomes trivial to group 
a list of people based on whatever relationship desired where the names in the list are links to their individual narratives.For this reason I choose to produce only Individual Narrative web reports, and share my genealogy with my relatives using web files on a CD. Even many genealogy repositories are starting to ask for family histories in electronic form rather than as printed reports. For me this web form eliminates nearly all the restraints caused by printed reports that are forced to be based only on certain fixed "standard" TMG tags and report structures. It is also why I am less concerned about these printed report restrictions and whether certain tags are "standard" or not.
This is just my bias
but hope this gives you further ideas,Mike,
thank you for your response. You surely give many ideas.
I fully agree with you about web-reports. Actually that's what I have been refering all the time, Journal report with HTML-output.
Genealogy is great fun, but it gets real value only if you can share your reseach. That's why I want publish as much info related to a person as possible.
Due to translation reason I have to focus only on 1-2 different reports, Journal report is the main one. Our language structure is complitely different so all help I get automatically from TMG is appreciated.
Peter
-
That would be fine, but wouldn't fix the list of children in the Journal which I thought was the idea.You really have to decide whether you want the questionable children to be displayed for the mother in the list of children in the Journal. If so, you have to attach them to her with primary relationship tags. If you are happy with a note listing these children, and not having them in the "official" list of children, a tag like you describe will be fine.
Either will work - which is best depends on how you want the data to display.
After some thinking I did choose additional tag.
However, the more I think this issue, the more I would like to see this as a build in feature in TMG. At least where I am from, thinking in all areas of life is getting more family oriented without "legal" binds. People are not married, but they create a family and children of a family do come from different fathers and mothers etc.
Now if we have a new couple which both have children from earlier marriages/patrnerships, from TMG point of view, families would look complitely different depending if we print husband or wife line. Family should allways look the same. So genealogy point of view TMG does it correct but family point of view we should do better job.
In Journal report we can choose "Include spouse events", however this does not include children of a spouse. And I would say that birth of a child is and real event.
My wish is that this would be thought to be a build in feature in TMG.
Peter
-
Looking at this again, I think I suggested the wrong solution. I'd now suggest attaching all the children to the mother, and then adding a JournalChildren tag to the two parents with wording something like: "The following are the children of Father, and Mother is clearly the mother of the last four, and most likely of the others as well."This way you have all the children listed for both parents, and accurately state what you know about their mother.
Thank you Terry again. I suppose this was what Roy mentioned earlier. This would affect to all relationship calculations etc. I see a smalll danger there.
However, I have not tested yet, but I had an other idea. To create a new tag where parents are principals and children witnesses.
Then principal sentence something like "He and she might have more children together named: "list of witnesses".."
Witness sentence "His/Her other mother/father might be ...."
Would this work? Comments please
Peter
-
I have a situation in Ritchie Co WV that I still haven't figured out. There may not be an answer. The same named child has two birth records on adjacent lines of the birth ledger. Both records have the same father. The first line lists the first wife as the mother and the second line lists the second wife as the mother. The birthdate is about a month after the marriage of the second wife, but I found no local death record for the first wife. With the internet and the SSDI now, perhaps it's time for another look.One or the other will probably end up as the primary mother, probably the second wife, but it's uncertain.
Good example in these circumtances, but sorry to say because genealogywise it is not that "good".
Anyway, from TMG point of view you end up having same problem as I do. Whenever you print Journal from either wife-line, you will not get this child mentioned at all. Would it be great to get these children mentioned one way or another.
-
Actually you can now quite easily solve this in TMG7.First, do not enter the supposed mother as the mother of the early children. Then, add a NarrativeChildren tag to the father alone, and perhaps another for the father and mother together. In each, customize the sentence to properly reflect the data - for example, have the one for the father alone say something like "Mother was most likely the mother of these children, but that has not been proved." In the one for both parents say something like "Children of Father and Mother include the following, and most likely those above as well."
Details of using the NarrativeChildren tag can be found in my ariticle on Customizing the "Children of..." Statement.
Terry/Roy,
thank you for your help. If I understand right this still does not get all children printed when printing journal from wife-line. Journal only prints children which has wife as a mother. I have selected in options "Include spouse events" but this does not print children (I assume in order to avoid dublicate list of children).
Do I do something wrong and not get early/additional children printed or maybe it cannot be done?
If doing like Roy says, it would work, but doing that way I might end up having incorrect data in database.
Peter
-
There is often a situation where all children of a husband are known. But exact date of marriage is not know so it is not possible to be sure that wife is a mother of earlier children.
Example: Children are born 1700, 1702, 1704 and 1706. Marriage is know to be before 1704 and it is known that children born 1704 and 1706 are children of the wife aswell.
It is very much assumable that children born 1700 and 1702 have same mother, but can not be proofed. So TMG7 point of view these children have father but not mother.
Now the tricky part. When printing Journal from wife-line, only those children where wife is listed as mother will show in report. I would like to get all children listed but separately and noted, because it is not proved that they are children of this wife.
I believe this is a quite common issue which some of you have allready thought about.
What is a best practize or any good way to solve this? All ideas are very much appreciated.
Peter
-
After several requests directly from tech support I got an answer last week ie. "It is know bug and will be fixed in future".
At least I know now that it is not only me having this problem.
Actually, it is not a big issue but annoying. At the moment publishing can not be done.
Peter
I have the same problem. Did yu ever resolve the issue? -
Compared to TMG6, in Journal report there is a new line added regarding Living info. Actually this new text has replaced "Has known children text". (See bolded sample below).
He/She is coming first and then living info.
Has anybody seen the same? And could you rcorrect/emove it somehow?
Peter
_________________________________
238. HEIKKI TAPANI PÄRNÄNEN (1549) (Toivo Seppo, Toini Katri Tarkkonen, Matti Pekanpoika, Regina Juhontytär Hyppönen, Juho Simonpoika, Simo Juhonpoika, Anna Ollintytär Kiukkonen, Regina Antintytär Rapo, Antti Ollinpoika, Olli Antinpoika, Antti) living.
AILA ANNELI LESKINEN (8432) living.
Heliving.
i. ALISA AMANDA (8433) living.
ii. MIRO TAPANI (8690) living.
_____________________________________
-
All kind of variables can be used in Place Mapping feature.
However, can ShortPlace be used and if yes, what is variable name for that?
This is due to finnish language. In finnish we do not use prepositions, instead the end of each place is changed based what we want to say. There is many endings matching to different prepositions. This make it very difficult to build sentences automatically. There is a sort of compromise available but city, county etc. names has to be entered with "endings".
But, when these endings are used, Google maps or others do not find the place. One solution would be to use place names in sentences and short place name in searches.
-
In tag sentence a variable [PARO] can be used to include parents of a spouse into a report (like Journal report).
Is there a possibility to add date of birth and date of death of parents aswell?
This would help others to identify parents more precisely.
Peter
-
Hi,I guess -correct me if I'm wrong - that Peter wants to have data shown from living people who don't object, but doesn't want to show information from living people who might object to seeing their data published. When using the "Suppress Details for Living People" option, however, it's everything or nothing.
What I would do is set the "Living" flag to "N" for those people whose information you want to display. For your database, they're dead, but they don't know they're declared "dead" and at least you don't have to tell them they have to wait until they're dead to see their data. As far as I see, switching the "Living" flag to "N" for living people will have no further consequences (but here I might be wrong).
Dirk
Dirk,
this is exactly what I meant. Your idea using living-flag is worth of investigating. Thank You!
Peter
-
At least in Journal report there is a feature to "Suppress Details for Living People". It is at least polite to do so but in some countries it is demanded by the law.
However, then there is people who would like to see their info included in web pages. And have given even written permission to do so.
What to tell to them? Today you try to tell then politely "wait till you are dead".
I have not found a way to solve this, maybe someone can help.
One possibility would be to have a system flag like "Release living info". If that is set to Yes, info would be released wether or not "Suppress Details for Living People is selected". Then releasing info could be controlled by person.
An other possibility would do in per tag, one way or an other.
In any case it will need software change in TMG.
Peter
-
In this case, it's not clear that you might be running into User Account Control but I can't see another explanation.Please read this document about how to run TMG 6.12 under WinVista.
This issue has been cleared at least to some level.
It was related to UFT to TMG data transfer, languages and custom made sentences etc.
Peter
-
Even if I delete all old sentences and the field looks empty, there is something in it.
Tag page does not show any custom sentences but whenever I open sentence field, it will open
empty custom sentence field. With tab default sentence field will be shown, but next time again empty custom page is shown first.
However, all printed sentences are based on default sentences.
Only problem this will cause is to find tags with custom sentences.
In project explorer filter "sentence is not empty" will list 377 people. Some have clear sentence field, some
have custom sentence in purpose.
I need to fix (=clear old custom sentence) 350 out of these 377 and it would be nice to do it correctly in the
first place.
In this PC I have Vista
Does anybody have a fix?
Peter
Error during Journal creation in TMG 7.03
in Older Products and Versions
Posted · Report reply
OK, problem solved. Issue was not fixable with reindex, optimize etc.
With excellent help from Phil in TMG support we found the reason to be corrupted data in Citation detail field.
How those were created is a bit unknown but most probably by myself when adding formating codes.
Complitely other questions then is should TMG stand this kind of situations without halting or crashing.
Once again thank's to Phil!
Peter