From: Jerome <rom...@ya...> - 2014-06-17 16:50:15
|
Enno, > 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). http://genealogyblog.geneanet.org/index.php/post/2011/12/New:-Edit-your-Places-in-your-GeneaNet-Online-Family-Tree-GeneWeb.html http://blog.geneanet.org/index.php/post/2011/11/Comment-bien-saisir-vos-lieux-sur-GeneaNet.html 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! http://www.geonames.org/ https://wiki.openstreetmap.org/wiki/MapQuest http://fr.geneawiki.com/index.php/Portail:Régionalisme https://github.com/DallanQ/Places/wiki/Database-download 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! ;) regards, Jérôme Le mar. 17 juin 2014 at 17:02, Enno Borgsteede <enn...@gm...> 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. > > regards, > > Enno > >> [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 >> >> > > |