I wonder why items such as “at” are not configurable (it is not possible to modify or delete the “at”)?
In an other langage than american english it’s not logical.
Here’s an example:
et <%décédée|décédée> le< [Date:Plain]> à< [PlaceDetails]>< [Place:Plain]>.
“Et décédé le 1518 à at Eglise Port-sur-Seille, Meurthe-et-Moselle, France”.
You may also need to move your prepositions for languages other than English inside the <angle brackets>. Otherwise, the prepositions will appear even if the associated RM variable such as [Place] or [PlaceDetails] is null.
It’s been many years since I played around with creating RM sentence template in a language other than English. I don’t remember the details, but I seem to remember that certain items in RM’s narrative reports are not under control of the sentence templates. If that is still the case, the only recourse might be to save the report as a DOCX file before printing and to make any needed edits in a word processor before printing. If you find that such edits are necessary, hopefully they can be accomplished via a global replace.
The answer to your question of “why” is simply that the present version of RM is really designed only for English. The only exception is that data itself is stored in Unicode (well, really in UTF-8) which means that data from most any alphabet can be stored as names, places, notes, etc. I think dates are 100% English, but I’m not sure about that. And in any case, sentence templates are very oriented towards English.
The RM developers have mentioned that they have future plans for supporting other languages, but there is no indication of when such support might appear or what it might look like. My personal wish is that such support might include multiple sets of sentence templates just like we now have multiple color sets. That way, you presumably could produce reports in more than one language from the same RM database.
Ah, now I remember the problem, and really there several different problems.
When using the NEHGS and NGSQ formats, families are printed with the parents and then a list of their children. Also, a child is carried forward to the next generation if the child has at least one spouse or at least one child.
If a child IS NOT carried forward to the next generation, then the sentences for that child in the list of children for a family ARE under control RM’s sentence templates. If a child IS carried forward to the next generation, then the sentences for that child in the list of children for a family ARE NOT under control of RM’s sentence templates and always are in English.
Another problem has to do with what I call the “spouse sentence” - namely the first sentence for a person’s spouse. It’s basically the sentence for the spouse’s Birth fact. But the sentence for the spouse’s Birth fact includes the names of the spouse’s parents and that part of the sentence is not under control of RM’s sentence templates. That means that any text about the spouse’s parents is in English. And for my purposes, I don’t want the text about the spouse’s parents to appear at all because I already include a Parents fact for everyone in my database who has parents. I am able to save an RM report as a DOCX file and to do a global replace using regular expressions to get rid of the names of the parents from the spouse sentence, but the whole report really needs to be under control of sentence templates.
Another possible problem is that RM uses a collating sequence that sorts non-English letters as if they were the English letter they most resemble. For example, a German Ü is sorted as if it were an English U.Such sorting only matters if you are generating a Name index and/or a Place index as a part of a report. I never got far enough along in my testing of RM with foreign alphabets to determine what happens to the sorting of non-English letters in a Name index or a Place index.
I remember that the Roots Magic team had the ambition in an earlier version to adapt the product to foreign languages (version 5 or 6?) If this project could become a reality, I’d be delighted and it would enable Roots Magic to find new customers.
In the meantime, I’ll settle for “Search and Replace”.
Thanks to both of you.
While it was written in the context of RM7, this page also speaks to your question with examples and only partial solutions.