I have finally bitten the bullet and commenced transfer from my much loved TMG to RM8. I am used to being able to duplicate a fact, such as a census entry across multiple people - not as a linked fact where if one person is deleted they all go, but as an individual copy. Have I missed something or is this not an available feature? Is there a recommended solution to entering something such as a 1851 census record across 5 or 6 people without having to enter it 5 or 6 times?
If you link multiple people to a census for example it copies it across all of them⊠if you accidently select the wrong âJohn Smithâ you go back into the last column (Share Fact). It will highlight all the people you have select to share within the right hand column. Highlight the one you want to delete, it will bring up Edit witness screen, from here you can delete that person (click on the waste bin top right). The census remains for all other people. Itâs something we have always been able to do in RM.
RM has no Copy Fact feature. It has been repeatedly requested for more than a decade.
3 Likes
Yes. That feature is sorely missed. In TMG, we would duplicate a fact and then transfer the fact to another person. Maybeaby 5 keystrokes.
RM does not have the copy fact feature despite it being a much requested feature for many years. The RM way to âcopyâ a fact is the use of shared facts. But doing it with shared facts is not even remotely the same thing as actually being able to copy a fact.
2 Likes
I worked with TMG for years and liked the copy event/fact option. One work around I have used in RM is to share a census or residence fact with several people. Then edit the shared personâs record to create a new event/fact using the data from the âsharedâ entry. Then you have an option of removing the share event/fact from that personâs role. With RM8, unlike RM7, windows for two people can be open at the same time so the method I describe may be obsolete. Certainly having a new copy fact feature in RM8 would easily allow one to copy a fact from one personâs view to another personâs view while both windows are open.
Many thanks to all for the information and helpful suggestions. While RM8 has many great features I am certainly finding data input often requires many more keystrokes and mouse clicks than did TMG.
OleSeminole I assume that there is no âautomated wayâ to copy the data from the shared entry to the new event/fact?
It is a question of copying and pasting or for entries like place can be picked from a list?
There is no automated way to copy data from an unshared fact or a shared fact to a new fact. So sharing a fact doesnât help with the process of creating a complete new copy of a fact.
You can copy and paste individual pieces of data from one fact to another - such as copying and pasting a data or copying and pasting a place. You can also memorize and paste a citation. The memorize and paste of a citation is a little different process than copying and paste a date or a place. But as for as copying and pasting a whole fact all at one go, the answer is no.
A process I use when I want to create separate facts for each person for the census is to create a shared fact/event for the Head. Then for each person in the census entry, I create a new census separate event , and then copy/paste data from the shared fact that is displayed for that individual. Itâs a laborious process but easier than entering (keying) data separately for each person. I would love to see a memorize and paste for facts in RM. TMG had that feature and I used it frequently.
1 Like
It is incredible that this oft-requested feature has never been implemented. I wrote a sqlite procedure to copy a fact to a group several years ago.
Yes. I really really miss that TMG feature
I use TomHâs updated sqlite script on a weekly basis but it would be great to have it part of RM8
I used also TMG, was a leader of a local user group in a part of Norway. TMG was translated into the Norwegian language. When TMG stopped updating, and Windows 10 was coming on, we were not sure if TMG could handle that. Our group decided to change to RM. Now our group covers the whole of Norway.
We have some trouble with the alphabet as there are three letters that are special in Scandinavia. Yes, RM has UNICODE, but that does not help. I do not know why, but RM8 handles these special letters otherwise than RM7 did.
1 Like
If you have a second, could you reply with a message that has those characters?
I use the German umlauted vowels and Ă often. Just wondering why youâre having trouble.
We have the letters ĂŠ, Ăž and ĂŠ, in capital letters Ă, Ă and Ă .
The problem is names, places starting with these letters are not sorted at the end of the alphabet as they should. When registering a place name starting with such a letter, it will not show up if you have that place already. You have to write the fully address every time. Searching on names starting with these letters will not give any luck.
The problem is that RM uses a special collating sequence that treats Norwegian Ă as if it were the English letter O and that treats Norwegian Ă as if it were the English letter A.
The Norwegian Ă is a little more complicated. The complication is that the Norwegian Ă is a single letter and yet it looks to the English reader as if it were a diphthong written with a ligature. For example, there is an epic English poem by Edmund Spencer called The Faerie Queene. These days I mostly see the ae in the title written as two separate letters without a ligature. Years ago I always saw the ae in Faerie written as a ligature, viz., ĂŠ or FĂŠrie. But to the native English speaker this is still two distinct letters rather than a single letter as in Norwegian. Itâs like the Ă in English is written in a funny font that uses ligatures and there still being two letters, rather than the Ă being a single letter as in Norwegian. In any case, RM treats the Ă as if it were the two letters AE written without a ligature.
I donât have any Norwegian names or place names in my database, so I hadnât noticed the problem of Norwegian place names not being picked up automatically when entering facts into the Edit Person screen. As a test, I entered place names beginning with each of Ă, Ă and Ă into my database. I was able to replicate the behavior you describe in the Edit Person screen in both RM7 and RM8.
I also tested looking up items in the Place list. In RM7, typing for any of Ă, Ă and Ă in the Place list doesnât find them. Instead, it finds Ae, O, and A, respectively, skipping over the Norwegian place names. RM8 does find all three Norwegian letters in the Place list, so this is progress.
I was really hoping that RM8 would abandon RM7âs special collation sequence and just allow non-English letters to be non-English letters instead of trying to fake them into being English letters. I think that not making that change in RM8 was a missed opportunity.
I see.
So itâs not just the sorting, it getting RM8 to recognize names so you donât have to type it all in.
This is the support ticket on a similar (same? issue) I submitted a week ago, and the response-
========================================
Your request (#111415) has been updated.
Richard Otter, Feb 3, 2022, 19:59 MST:
RM apparently thinks à and ö are different characters that are not just upper/lower case of the same character.
In the people index, if I type ö,
I will see all of the names that contain a lower case ö
But I do not see names that start with Ă
To see these, I need to type Ă
Probably a very simple fix.
========================================
To review the status of the request and add additional comments, follow the link below:
http://support.rootsmagic.com/hc/requests/111415
You can also add a comment by replying to this email.
Renee, Feb 4, 2022, 16:44 MST:
Richard,
Unicode or umlauts characters are case-sensitive in the index lists, other characters are not. This is a limitation of the programming tools that we currently need to work around.
Sincerely,
Renee
RootsMagic, Inc.
========================================
I am so sick of that âlimitation of the programming toolsâ excuse! I would love to know what lame tools they are using.
I think that problem is a trickier and harder than it may sound, but I do think RM could do much better than it is doing to support many of these letters.
It seems to me that there are two problems to solve. The most obvious one is just getting the letters into the correct order. For example, the Norwegian letters Ă, Ă and Ă must come after the letter Z to work correctly for Norwegian. But there are many letters and many languages. I donât think there is a way to get all the letters in the correct order for all the languages all at the same time. RM or any software that is ordering letters would have to know which language they were dealing with. If you threw Norwegian names and Russian names and German names and Greek names all into the same list of names, there is no one ordering that would be satisfactory for all the languages.
The other problem to solve is case insensitive ordering so that A and a are sorted the same as each other as are Ă and ĂŠ and all other combinations of upper case and lower case letters. I think this particular problem is solvable without necessarily being tied down to a particular language locale.
Therefore, I think RM can and should do the following.
- Quit trying to make non-English letters be ordered in the same manner as the English letters that they most resemble. At a bare minimum, that would mean abandoning RMâs existing collating sequence. This would be an extremely easy step that would require no new technology at all. It would at least get Ă away from Ae and Ă away from O, etc⊠It still would not order Ă the same as ĂŠ nor Ă the same as ö. But itâs low hanging fruit, and itâs a step in the right direction.
- Create a collating sequence for RM that would order Ă the same as ĂŠ and Ă the same as ö, etc. If RM can create a collating sequence that orders Ă the same as A, then surely RM can create a collating sequence that orders Ă the same as Ă„. It seems to me that this step could be done without knowing the language locale. It wouldnât get all the letters in correct order for all the languages, but it would separate the letters from each other and provide for case insensitive ordering for non-English letters.
Ultimately, RM will need to support language locales, but I think thatâs a much harder problem. I donât think my suggestions would require any new programming tools. I think they could be done with existing programming tools.
In the long run (and probably it would be a very long run), RM would need to define collating sequences for each language locale. These collating sequences would have to be associated with an RM database at the time the RM database was created. I think this is a very difficult problem.