From: Frederico M. <fs...@gm...> - 2009-09-10 17:27:25
|
Hello again, 2009/9/10 Benny Malengier <ben...@gm...>: > 2009/9/10 Frederico Muñoz <fs...@gm...>: (...) >> Additionally I'm unsure how GEDCOM import would work out. > > As GEDCOM has no provision for it, there is no way it can be included > and made to work. > There is no reason to do GRAMPS --> GEDCOM --> GRAMPS > So adding new fields to GEDCOM only GRAMPS knows adds no value. Time > is better spend cleaning up import of GEDCOM which would just keep the > names as stored, and add new ones present in the GEDCOM. Indeed, I was not aiming at doing some "smart" importing, since at least around here it would likely be very difficult to do and with less than stellar results. >From Julio's latter message though it seems that at least there are some valid ways that some might use (the SURN tag) that could have some impact, but this is something more general (i.e. assuming that what PGV did is valid GEDCOM how will GRAMPS handle the importing *today*). > As a consequence, the way to support it, is to import names as now > from GEDCOM (with addition for support of nickname that is present in > GEDCOM) and offer a plugin tool 'Cleanup names' that can batch process > names so as to split up surnames. Yes, a plugin could be e good idea, since it would leave to the individual the choice. > That tool should eg allow for: > * split multiple surnames as <secondary surname> <primary surname> > * split multiple surnames as <primary surname> <secondary surname> Right. > I am only unclear in how to handle the binding y. Is it ok to consider > this a prefix? Probably not, but then the y should be part of > secondary surname field, so as to make printing work correctly. I > would think it is not too much of a bother to have that there if you > want it, after all, you know what it means. >From Julio's latest example one can see that this can get rather complex. > Adding a field (surname combine field) just for the 'y' looks like > overkill to me. The usage will be so specific per culture, with > probably some exceptions too..... True, which is why aiming at something more general is, if at all possible, better, since trying to provide input fields for every details will in the end be overkill and could even be a limiting factor given the wide array of choices. Regards, Frederico |