When a Dutch user types OKTOBER in a date field on FamilySearch, the site recognizes this, and stores the date in such a way that English speaking users see OCTOBER, French users see OCTOBRE, and so forth. The site also stores the date as entered, even though in this case, that wouldn’t be necessary, because a standardized date can always be shown in the visiting user’s locale.
When RootsMagic retrieves this date however, it seems to rely on the stored text, and not the normalized date, so that I see Oktober in red, as if it is an illegal date, even though I can recognize that, because I am a Dutch speaking user. And I can understand that, because RootsMagic is an American program.
Since this can create all sorts of nasty problems, especially when a date is not as easy to recognize as Oktober, I suggest that RootsMagic retrieves the standardized date when available, and I know that it is, because Ancestral Quest downloads that, and it is available in the GEDCOM X data model:
So, what I’m asking is that RootsMagic retrieves the formal date field when available, and only relies on the original if the formal date is empty or undefined.
P.S. It looks like the forum software can’t deal with an HTML bookmark, so you need to click the URL to see what the site says about dates.
First, I wouldn’t hitch my wagon to the GedcomX standard. That standard has gained about zilch for traction. Secondly, do you know that for certain that FamilySearch’s API allows access to the date formats that you mention? If it doesn’t then RM isn’t going to be able to do much until it does.
I know what I’m talking about, because the FamilySearch API is one of the few places where the GEDCOM X is used. And I also know that Ancestral Quest does this right, and although it supports more languages than RootsMagic, it doesn’t speak Dutch.
The text below is a direct quote from the official FamilySearch Developer Center:
and when you read that, you can see that there is a similar choice for places too. And in fact, when you import data from FamilySearch, Ancestral Quest asks whether you want the original or the normalized place. This may not be necessary in RootsMagic, because one could store that in the place details.
If you want, you can read the full example from which I quoted here:
Or look at a real life example in the Family Tree:
In both cases the forum site doesn’t show the actual data, but you can see it when you click on it.
That is a perfectly reasonable enhancement request consistent with many previous ones having to do with internationalisation and multi-language support, which was once upon a time a declared objective of the developers, expressly delayed by the effort involved in the transition to SQLite from the pre-RM4 database platform.
Transposing international dates has always been an issue for me and I had requested that the date field be added to “search and replace”. I have to deal with a lot of French dates plus a few others, and when I have brought info from FS into RM it will never sort properly until I manually go in and change the sorting dates. Most dates in other languages are recognizable, but it doesn’t help with sorting. This has always been my biggest drawback for these programs.