I saw in another post that name changes should work if they are entered in the Alternative Names section. Mine does not work.
I have the name St Thomas’ Church as the main name. It was located in Toxteth Park, Lancashire, England from 1086 to 1800, when the name changed to just Toxteth, Lancashire and in 1974 it changed to Toxteth, Merseyside, England.
I entered a Marriage with the date 1844-12-08 and it is displayed in the Family record as St Thomas’ Church, Toxteth Park, Lancashire, England.
The question mark (?) appears when there is no valid option based upon the date of the event.
You can filter the event list by closing the sidebar filter and setting the column filter to search on the Place field. Place contains ? to find entries with the name problem.
After identifying the place record, based upon the date of the event, does the place record have a valid name option? And understand that the ? may be a place holder for a record in the hierarchy.
That search doesn’t work for finding this problem. While it searches on the actually concatenated Place Name fields, not in the date-adjusted and calculated Place Title. So, it finds Events where the ? is actually specified in an enclosing Place name.
(My tree has 1 Place name that was created as a hierarchical placeholder. It represents a probable typo in a book. It was called (Invalid?) Logan (TN) county. Searching the Place for ? finds only the single event that has the Place title of Midway, (Invalid?) Logan (TN) county, Tennessee, USA, North America
Sorting Events on Place column only helps find the problems where the ? is at the top-level, but not the ones with an Enclosing place problem. (Found some Events with 2 different top-level Place Title problems. 1 was appropriate … where the wilderness place was only settled and given a name 2 years after the event in question. (Not sure how to deal with that.) The other, I added exact duplicates of the Alternative Name records and deleted the originals. Which somehow corrected that particular problem.
And another odd part is that problematic Place Title is different in the Event Editor than in the Events category table.
Here is my list of places producing the question mark. They are all from the Germanic regions of Europe. I have not yet fixed them because I want to trash what I have and start over for this area.
Picking the 1876 birth in Schwerin I have it enclosed by the Mecklenburg-Vorpommern record. I currently have this record bouncing between the name Mecklenburg-Vorpommern and just Mecklenburg with the earliest naming dates starting 1 Jan 1934. There is no naming option (or enclosed by records) to produce a complete name.
the dates in the Alternate name don’t seem to do anything.
The Help files states “Date: Date range in which the place is valid”. It does not indicate that the system will change the name based on the date.
Based on this, I don’t think the “date” has any relevance in the program except for maybe informational purposes.
I created a new event with the date 1985, a new Place called Northtown with an alternate name Southtown. Southtown has a date of 1990. I tried just Southtown as the single alternate name and when that had no effect, I added Northtown with a date as “after 1991” and Southtown before 1990 (no overlap).
Nothing worked as expected. I can use the search and find these names. I do use the same feature in the Enclosed By section and that works.
So I have to conclude that if the name changes, you have to treat them as a separate Place and create a new entry.
Edited to add: If a date is entered and the date of the event is outside the ““valid” period for the Place, the Place shown in the event does not indicate that the name is invalid like putting ??? in the field or turning it red.
An empty date will match all dates. If you leave the date field of the main name empty, then it will always match before any of the alternative names are processed.
The event editor always displays the modern name of the place.
At the end of the main place Name field there is an Edit icon which opens the edit window exactly like entering/editing an Alternative Name entry. This place name needs to have date information. If left blank, as the first record Gramps will consider, it will match as valid for any and all event dates. If this entry does not return as true for the event, only then does Gramps look at the first entry in the Alternative Names list, then the second, etc.
You mentioned adding dates in ALL the alternative names and eliminating the the overlap.
But you did not mention what dating you entered for the primary Place name. (That date information is critical to the proper function.)
I generally try to have the modern name as the primary one.
So try this experiment:
Add a place with 3 dated name ranges in the Example.gramps tree. (No sense contaminating your working database with experimental data.) Make the date ranges explicit to eliminate the approximation ambiguities.
OK, now I feel stupid for never clicking on the edit icon which I assumed (made an ass of myself) just was for editing the text.. The screenshots all look the same.
Now I get it, thanks. I did test it and it does work if you put the date in the right spot.
I originally did not realize there were additional attributes for the Primary/Preferred place name either. @DaveSch had to enlighten me a few years ago.
I believe there was discussion of an enhancement request to make the “Alternative Names” tab in the Place Editor more like the “Names” tab in the Person Editor… where there is visibility of the Preferred (Primary) and its extended attributes in the same space as the Alternative ones. (That GUI tab also facilitates swapping the Preferred using a drag’n’drop.)
However, there was an expectation that writing this enhancement request should be deferred. Because the Place data table was being restructured and the interface would be evolving around that change.
That deferral might need to be re-thought since the revision the Place handling seems to have fallen off the roadmap.
I agree with @emyoulation on this. I respectfully submit that this is a poor GUI design. The same functions should not be split up within the same screen.
remove the edit icon beside the preferred name
show the preferred name in the alternate name tab.
In the Alternate Name tab, dates can be attached to the preferred name and other alternate names added as it is today.
In this way all the names can be seen and the dates in one place.
There is no reason to remove the icon. To be consistent with the Person Editor interface, it should have that icon too. A button allows the Name editor to be opened with a single-click. (Which is more compliant with touch-screen GUI guidelines.) The rows in the Names tab require a double-click.
So, to be more consistent as a GUI, the “Alternative Names” tab labeling could be simplified to “Names”. And add the identically labeled collapsible subheadings for “Preferred name” and “Alternative names” (plus a count of the alternative names). And we should eliminate “Primary name” or “Main name” from our vocabulary for the Place name alternatives.
However, perhaps there ought to be a fallback (default) name for when the Preferred date has limits defined? Just as books tend to have a variety of parenthetical stylings to deal with such ambiguities. Such as (the Pueblo Bonito ruins in Chaco Culture National Historical Park, New Mexico) or “Waterloo (predecessor of modern day Austin, Texas)”
I thought about what @emyoulation said and I disagree with leaving the icon to open the name editor for the Preferred name. It means that the function remains split between two sections in the screen, all to save a single click. When all the functions are consolidated under the Names tab, no one will use the single purpose icon. Saving one click for one function is not conducive to creating a clean and improved interface. Just my thoughts.
