* Umlauts and accents

[E Wilcock]

Calico Pie explained that on my little touch screen Windows 10 lap top the normal fh action of holding the key down to get accented letters would not work.
But it doesnt seem to work when I write a place name into queries using my desktop Windows 7 either.

Have I set an option wrongly somewhere?

This is driving me mad. My family came from Würzburg, sometimes spelled Wuerzburg or Wurzburg. So I need three lines to cover those and I expected FH to be better at accents than TMG.
Calico Pie know these things. But it isnt clear to me whether the program is still under active development?

I would like to ask other people too how they handle different spellings of place names when writing queries. Especially where a name in English differs from the source in German. Hanover and Hannover upset me a good deal.

[davidf]

Evelyn,

(Whether this lives under "Umlauts and accents" or gets moved to a new query, I am not sure)

I would like to ask other people too how they handle different spellings of place names when writing queries. Especially where a name in English differs from the source in German. Hanover and Hannover upset me a good deal.

In queries you can use the standardised form of a place %FACT.PLAC>STAN%; does that offer you a way forward? Each variation of place name (Würzburg, Wuerzburg or Wurzburg) is resolved to the same standard form (which ever you prefer) and you then query for the standardised form.

As an aside I know standardised forms are meant to get round how place names may have evolved (thinking of places that may be in London or Middlesex etc at different times - possibly also the various form of Germany/Prussia etc.), but my mind blows when I want to query for places say in Surrey in the C19th (think Southwark or Kingston)!

I think I need to be very careful that the non standardised form (of place name) is not the auto complete form but is the historically accurate form - which should be the form on the source? But if you want the place name to be "place as on source", you might for instance get "Queenstown" and nothing else. The historically complete form would be "Queenstown, County Cork, (Munster,) Ireland"; the standardised form would be "Cobh, County Cork, (Munster,) Republic of Ireland" - three different forms and only two ways to store them!

[tatewise]

As a matter of interest, did Calico Pie explain why it won't work on your little touch screen lap top?

The FH Help page Configure Language and Accent Characters Dialog says it only works in a "text field in the Property Box or in the AutoSource Citation Pane", so it is not supported elsewhere such as the Query Window, etc.

The method to use in those windows is the same as prior to FH V6.2.3 which involves the Alt key or the Character Map as explained in how_to:entered_accented_and_other_special_characters|> Enter Accented and Other Special Characters.

I don't have a significant problem with alternative spellings of Place names, but here are some thoughts.
Since they are all the same place, there should be only one Place record regardless of all the spellings.
(That is the same concept as people who should have only one Individual record regardless of their name spellings.)
In a Place record the main name should be the most popular.
The Standardized field should hold the modern spelling to make auto-geocoding more successful.
The Note field should explain the alternative spellings as found in various Source documents.
The Source documents themselves will contain the place name spelling as found therein, but associated Facts will show the Place name as per the Place record.

I guess an alternative is to have a separate Place record for each spelling and all with with the same Standardized field (as suggested by davidf) and Lat/Longitude geocoding, and perhaps some cross-reference to each other in their Note field.

[davidf]

Since they are all the same place, there should be only one Place record regardless of all the spellings.
(That is the same concept as people who should have only one Individual record regardless of their name spellings.)
In a Place record the main name should be the most popular.
The Standardized field should hold the modern spelling to make auto-geocoding more successful.
The Note field should explain the alternative spellings as found in various Source documents.
The Source documents themselves will contain the place name spelling as found therein, but associated Facts will show the Place name as per the Place record.

That certainly is a rigorously correct approach in terms of database design and living strictly within the constraints of the GEDCOM database definition.

But

In some cases the place name and the place can semantically be different. A place is arguably a single location which can be geo-coded - and thus should only have one place record. Place names are labels applied to a place which carry significance either historical, cultural or political. GEDCOM does not recognise place names as distinct entities.

Cobh may be the most "popular" label for the place that is the port near Cork City. But would you say that a passenger list for the Titanic shows people embarking at Cohb or Queenstown?

Likewise I would not say that my Irish Grandfather (b 1893) was born in "Belfast, Northern Ireland".

It is also a nonsense to say that George I was born "in Germany" - a state that did not exist at the time of his birth. I believe he as born in "Hanover, Brunswick-Lüneburg, Holy Roman Empire" - a state that no longer exists.

In diagrams and reports surely you want the appropriate place name label to show - and that would normally be what was written on the source. Extracting this from a note is laborious and using the place field would seem to pragmatically be the best place to input such a place name. To handle this we need to treat the "place" as a "place name" and resolve multiple place names by treating the "standardised name" as the single geographically located "place".

This breaks the database concept of one record per entity - as the standardised place will appear multiple times - and could acquire multiple standardised spellings due to input errors! But the benefit is that the initial place of access (diagram or report or even record window) will probably show the name most appropriate to a researcher. Questions like "have I already entered a 1901 Census entry for "Samuel Williamson, tinsmith, in Queenstown" is a lot easier if it is not showing as "Cobh".

I guess this is another situation where you need to decide for yourself the convention that you are going to use for your research and then to consistently apply it - and to be aware of issues that may occur when sharing data with other researchers.

[AdrianBruce]

...
In some cases the place name and the place can semantically be different. A place is arguably a single location which can be geo-coded - and thus should only have one place record. Place names are labels applied to a place ...

Oooh - interesting - or rather, interesting if you are interested in Data Modelling and like challenging your logical abilities. (Feel free to tune out if you're not).

For what it's worth, the FamilySearch Standard Location Database contains a record per place and each record will have one or more place-names that ought to be branded with the dates that the particular place-name for that place was valid. Thus "Nantwich, Cheshire, England" to start with and "Nantwich, Cheshire, England, United Kingdom" from 1801 onwards, are the place-names that are part of the same record for the place usually known as Nantwich.

Unfortunately, FamilySearch spoil all this in many ways by (e.g.) omitting place-names ending in "Great Britain" (1707-1801); using "Germany" as the "country" after the fall of the Holy Roman Empire in 1815 rather than from 1871; inventing concepts like "British Colonial America" for the British colonies in the Americas; and by just plain omitting the dates form a big portion of the place-names.

Conversely it is a huge undertaking to assemble such a database.

[E Wilcock]

A belated thank you. And for the detailed guidance. I will look carefully at the information about place name variants. I have paid little attention to Places.
Mike - I looked out the correspondence with Calico Pie about my Windows 10 Lenovo touch screen lap top - many adjustments were made to my settings and my project file sent to them. But it wasnt solved and was attributed to modern touch screen devices.

I thought the behaviour on the desk top with Windows 7 was fine. Then it cropped up. I dont mind having to use the MS character map.
What annoys me is that if I forget that fh accents dont function in a pop up box it and hold the key down, it insert strings of the vowel instead. that is it repeats.
However, experimenting as I type this, I see that repeating when one holds a key down is a feature of my browser or Windows or something unconnected to fh and Calico Pie.

Once again, thank you for your help. I may well have forgotten things you taught me when I started.

[tatewise]

So regarding the Lenovo laptop, are you saying it has no keyboard, and everything is entered via the touch screen?
Or is it you could not find the Character Repeat settings in Keyboard Properties which is not in Windows 10 Settings but in the old Control Panel under Keyboard or via a Search.

Yes, holding down a key to auto-repeat a character is a long-standing basic Windows feature.
If you wish, you can make the Windows auto-repeat very slow so it does not happen by accident.
In FH you can change the Tools > Preferences so you must hold the Insert key down while pressing a character to get the Accent Characters dialogue, and that should work even on the Lenovo laptop.