> Here too, but there are too many levels for Dutch to understand, so I now see Province and Provincie, and I don't plan to do anything about that.

I suppose that nl.po uses something like:

Country: Provincie
Province: ""

You can also translate now, by:

Country: Country (Gedcom)
Province: Provincie

True, it is cosmetic, even on gedcom export, but it can explain the history of this level/type into current gramps' place hierachy handling.

> Another way would be to choose the city type, because that works for most locations, but that still is a wild guess.

Not certain that all places have a city ...
All places have/had a country (or sometimes/often more than one).

What about a simple event like emigration to the USA ... 
or Nouvelle-France, New-England, New-Orleans !
What will be the city? Otherwise, "city" is maybe not the 
right level for a simple farm?

Anyway, I suppose it is possible to move to "Unknown" or set a default type, but it looks like minor because user can fix the data by itself!

About internal places database, it is a little bit funny to see editors having hardcoded tables, now to have to rebuild them because there will be a change on current place hierarchy (eg, in France from 1960 -> to 2015).


To maintain a places DB (at least for France with around 37 000 cities!) is not something we can do just for fun ... In the past, I played with some open data (gramps, french gov.), but it is clear that most editors promote their own data set, via a wiki or whatever "private collaborative" hosting!

etc ...

PS: by looking at one blog, I saw: http://genealogyblog.geneanet.org/index.php/post/2014/03/Geneanet-Job-Offer:-Genealogical-Data-Manager.html
if someone needs a job! ;)


Le mar. 17 juin 2014 at 17:02, Enno Borgsteede <ennoborg@gmail.com> a écrit :
Hi Jerome,
It looks like that we are few to test and play with master/gramps41, before a release...
Yes indeed.
Some weeks ago, I got problem with translation strings around labels/words for place levels. It takes some days, but I think that now it looks better, under my locale.
Here too, but there are too many levels for Dutch to understand, so I now see Province and Provincie, and I don't plan to do anything about that.
Sure, old gedcom model is also a problem because it is based on US levels. eg, no county or state in France (maybe no state everyelse than in the USA?).
Well, as far as I see, GEDCOM doesn't prescribe anything, because the PLAC tag as used in events is followed by a string that can contain anything. Putting Amsterdam, Noord-Holland, Nederland there, is just a convention, which I don't follow, because it is not understood by American sites.

The levels that you are referring too, which are in the ADDR structures, are rare, because they are not used by events, which use the PLAC tag instead.
Since many versions, my locale used a global translation matching county or state (Belgium, Switzerland, Canada, Fance, etc ...) and since while I do not trust gedcom specification for properly handling place levels!
Right, see above.
Like for Source, maybe the title (place or source) is the only one inherited gedcom field which is consistent according to all possible declinaison of gedcom files? [1]
Yes, and for both title and source, this is a nuisance, because composed place titles and citations are language dependent. I mean that, where I might use

    Amsterdam, Noord-Holland, Nederland

FamilySearch uses

    Netherlands, Noord-Holland, Amsterdam

in the catalog, and likes to normalize it to

    Amsterdam, Netherlands

in their on-line tree. And other sites like Ancestry and WeRelate.org have yet another title for this.

For one of my German ancestors, the FS normalized place of birth is

    Spenge, Spenge, Herford, Nordrhein-Westfalen, Germany

where their catalog says

    Germany, Preußen, Westfalen, Spenge

This catalog is quite weird, because this is not a true hierarchy. Germany and Prussia are mutually exclusive, and should therefore not be in the same string. For my French ancestor, I can however live with the FS normalized Montignac-le-Coq, Charente, Poitou-Charentes, France.

When you exchange data with the FS tree, via Ancestral Quest, or RootsMagic, or whatever you like, you will encounter the normalized names, not the catalog, so the problem is not that big, but IMO a hierarchy will remain hard to use until all levels can be translated automatically.   
To have country as top level is maybe the less inconsistent level when importing data from any gedcom file? Agreed, to move the "unknown" when code does not know, is maybe more right.
I think so, yes, because the string in PLAC is undefined. Another way would be to choose the city type, because that works for most locations, but that still is a wild guess.
Note, it seems that gramps will create new place objects.
If something is not properly set, then we can edit, merge, select or remove data, like for every gramps objects. Locations were never filled after a gedcom import, right? If so, maybe import and gedcom with this autocompletion looks more complete than before!!! even, not matching the expected level type... Gramps is maybe not ready for a semantic support after importing a file format without at least [2] a consistent way for handling semantic markers?
Indeed. From what I've seen, and Nick told, Gramps will use a hierarchy when 3.4 location fields are filled, but if they are empty, no hierarchy is used, just like in GEDCOM import. Auto completion can be done with the tool that we already have, but that tool uses a built-in table, which is hard to maintain. Using a web service for this might be better, and such services exist, but I have no idea how to address such a service from Gramps.

Note that the GedcomX PlaceDescription type has no hierarchy like Gramps, and some of the web services that I know, but is just a list of names that can use different languages. The latter is nice, but may also become quite a mess, I think. FamilySearch probably chose this, because it is compatible with the normalized places that they already have, and can be extended with localized normalized names, but it is not very compatible with what we have now, because in their system, there are no types. You can recognize levels in a normalized string, but you don't really know what type these levels are.

One can say that for places, this is not much of a problem, because levels are easier to recognize than fields in a complex citation, where the language dependent part is much worse, because in a formatted citation it is not just country names that need translation, but also words like "accessed", "page", etc.



[1] http://bettergedcom.blogspot.fr/2011/01/further-place-names-in-gedcom-file.html
[2] https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#conclusion-place-reference