Als Programmentwickler kann ich es mir nicht leisten, einen Anwender im
Regen stehen zu lassen. Egal, ob Gedcom 5.5, 5.5.1 oder eine fehlerhafte
Gedcomdatei. Die Daten müssen bestmöglich importiert werden, damit der
Anwender möglichst wenig Probleme hat.
das würde ich auch so sehen und das klingt deutlich freundlicher als vor ein paar Tagen. Dann war "So wie kein Programm hier einen SOURCE_RECORD erwartet. Das führt somit zwangsläufig zu Datenverlust" offenbar missverständlich.
Nur um es klarzustellen: Der Autor von TNG ist außerordentlich hilfsbereit - der in bestimmten Teilen chaotische Export von GFAHnen hat ja nichts mit ihm zu tun und muss von ihm auch nicht ausgebügelt werden.
Nur um es klarzustellen: Der Autor von TNG ist außerordentlich hilfsbereit - der in bestimmten Teilen chaotische Export von GFAHnen hat ja nichts mit ihm zu tun und muss von ihm auch nicht ausgebügelt werden.
Das sehe ich anders. Wenn ein Kunde zu mir kommt und auf mein Programm wechseln will, aber die GEDCOM nur verstümmelt übernommen wird, dann bitte ich ihn um seine GEDCOM, schau mir die an. Und dann gibt es zwei Alternativen: Die ist korrekt, aber mein Import-Modul kann das (noch) nicht verstehen. Oder aber da sind falsche Sachen drin entgegen dem GEDOCM-Standard. Und auch jetzt habe ich wieder zwei Möglichkeiten: Ich kann oder will das nicht bei mir einbauen. Oder ich setze mich hin, investiere Zeit, und mein Programm kann hinterher mehr verstehen. OK, es gibt eine dritte: Das exportierende Programm hat dermaßen Mist geschrieben das man das beim besten Willen das nicht einlesen kann.
Ich persönlich tendiere in den allermeisten Fällen zu Alternative 2. Schon alleine aus purem Egoismus (mal ganz abgesehen das mich die Herausforderung natürlich auch reizt): Will der Kunde zu meinem Programm wechseln muß ich ihm den Weg auch bereiten. Und mich nicht hochnäsig auf die Hinterbeine stellen und sagen: Selber Schuld wenn Sie vorher mit Programm gearbeitet haben das nicht mal eine ordentliche GEDCOM hinbekommt.