Nach dem informativen Vortrag von David Straub über GrampsWeb habe ich heute direkt das Desktop Programm auf Windows 10 ausprobieren müssen. Der Ansatz Open Source und die vielen Details, Ergänzungsmöglichkeiten und Links gefallen mir sehr !
Meine TEST.ged Datei stammt aus Ahnenblatt 3.60 und hat 60 Einträge; Zeichencodierung UTF-8, GEDCOM: 5.5.1
Das hat gut geklappt und sieht vielversprechend aus ! Vornamen, Spitzname, etc. alles super, 
ABER …
… kleiner Haken der viel Nacharbeit kosten würde: die GEDCOM Zeile „_RUFNAME“ wird nicht interpretiert. Der Import meldet: „Die Zeile wurde ignoriert, da sie nicht verstanden wurde. Line 334: 2 _RUFNAME Christian“
Möchte ich für meine 700+ Einträge nicht unbedingt nachtragen müssen 
Gibt’s da von Euch irgendeinen Tipp, Hinweis, Hilfe, Workaround ?
Viele Grüße in die Runde,
Christian (Hotop)
Hallo Christian,
die Unterstützung von _RUFNAME wurde in Gramps 5.2.0-beta1 implementiert, siehe NEWS. Damit sollte es funktionieren. Aktuelles Beta ist Gramps 5.2.0-beta2, ich würde das mit dieser Version testen. Da es aber eine Beta-Version ist, würde ich wie folgt vorgehen:
- Installation von Gramps 5.2.0-beta2 parallel zu Gramps 5.1.6
- Export der Daten aus AB 3.60 nach GEDCOM
- Import der GEDCOM-Datei in Gramps 5.2.0-beta2
- Export der Daten aus Gramps 5.2.0-beta2 nach Gramps-XML
- Import der Gramps-XML-Datei in Gramps 5.1.6
Im Gramps-XML ist der Rufname das XML-Element call.
Viele Grüße
Steffen
Edit: mit der Antwort von Steffen sich meine Antwort erledigt
Leider unterstützt Gramps die Erweiterungen der GEDCOM-L Gruppe nicht. Damit können _RUFNAME und die Ortsdatensätze _LOC nicht importiert werden.
Ob es eine Umgehungsmöglichkeit gibt, weiß ich nicht. Aber ich empfehle Dir diese Frage im Gramps-Discourse zu stellen. Dort wurden alle meine Fragen immer sehr schnell und kompetent beantwortet.
PS: Ja, der Vortrag von David gestern war rund und sehr informativ.
Danke Steffen: Beta2 mit XML Im,- und Export wird schnellstens getestet …
… und Dank an Hermann (Gramps-L gefunden und vorgemerkt, hatte den vorhin übersehen)
Die Zeilen, die nicht verstanden wurden, enthalten benutzerdefinierte
Kennzeichen. Da hat sich das exportierende Programm also etwas eigenes
ausgedacht um Informationen zu sichern.
Da diese selbst ausgedachten Kennzeichen üblicherweise lediglich dem
exportierendem Programm bekannt sind, werden sie im Regelfall von allen
anderen Programmen nicht verstanden.
Falls entsprechende Gedcomanpassungen für das neue Genealogieprogramm notwendig sind, welche nicht mehr mit dem Editor zu bewerkstelligen sind:
Kann dies zum Beispiel mit GEDTool oder mit Gedcom Konvert (Gedcom Service Programme) bewerkstelligt werden.
→ damit die Portierung verlustfrei verläuft.
Damit kann man aber auch keine benutzerdefinierten Kennzeichen in etwas
GEDCOM-konformes umwandeln, wenn man nicht weiß, was das Kennzeichen
bedeutet.
Man kann damit aber fehlerhaft exportierte Kennzeichen/Informationen an
die Vorgaben des GEDCOM-Standards anpassen.
Natürlich kann man mit diesen Werkzeugen benutzerdefinierte Kennzeichen in Gedcom-konforme Strukturen bringen.
… das ist ja der Sinn und Zweck dieser Tools!
(allerdings muss man wissen was man macht und was es bedeutet! 
)
… nur machen muss man dies.
Nix für ungut, Metti
Schöne Grüße
Heinz
Wurde Davids Vortrag über Gramps Web aufgezeichnet? Und ist die Aufzeichnung verfügbar?
Jeder Teil der GEDCOM-Daten, der beim Import nicht erkannt wird, wird als Notizen gespeichert. Das SuperTool-Add-on ist gut darin, viele Daten von einem Ort an einen anderen zu verschieben. Es könnte ein gutes Tool sein, um andere Importprobleme zu beheben.
Außerdem sollte Gramps 5.2 bald verfügbar sein. Aber seien Sie vorsichtig mit der Beta-Version. Machen Sie häufig Backups.
(Verzeihen Sie die schlechte Grammatik. Ich verwende Google Translate aus dem Englischen.)
enjoy
Diese Nachricht ist im Thread. Aber Google Translate hat Probleme mit den Indexseiten des Forums. Und mein Deutsch ist zu schlecht, um die nicht übersetzten Seiten zu lesen.
Gary Griffin hat seit Version 3.3 die ersten PDF-Gramps-Benutzerhandbücher erstellt. Allerdings muss für jede Sprache das Skript angepasst werden.
Er startet die deutsche Version des herunterladbaren PDF-Benutzerhandbuchs. Es sind einige muttersprachliche Leser der deutschen Sprache erforderlich, die die PDFs überprüfen und Korrekturen vorschlagen.
Wer hat Interesse zu helfen?
Genau das meine ich.
Wenn man nicht weiß, was für Daten mit den benutzerdefinierten
Kennzeichen übertragen werden sollen, kann man daraus auch keine
GEDCOM-konforme Struktur bringen.
Zudem gibt es Dinge, die in GEDCOM nicht vorgesehen sind.
So bietet mein Programm Anwendernotizen je Datensatz an. Das sind
Notizen, die der Anwender für die weitere Suche anlegen kann oder mit
denen er sein Gedanken zur weiteren Suche festhalten möchte. Also keine
Daten, die zu der im Datensatz festgehaltenen Person gehören.
Dazu gibt es nach meinem Kenntnisstand in GEDCOM (5.5.1) keine passende
Struktur.
Sehe ich auch so. Das GEDCOM-L-Addendum hat hier wie bei _RUFNAME einen gut ausgearbeiteten Vorschlag: _TODO.
GrampsWeb hat für die Forschungsaufgaben sehr gut ausgefeilte Funktionen (mit Priorität, Status, etc). Gefällt mir sehr gut. Und der Rufname kommt ja dann in der nächsten Version.
Ich kenne das Addendum durchaus. Dennoch habe ich dann weiterhin
benutzerdefinierte Kennzeichen und kein GEDCOM 5.5.1.
Es ging ursprünglich darum, mit einem entsprechendem Programm (Werkzeug)
die benutzerdefinierten Kennzeichen in eine GEDCOM-konforme Struktur zu
bringen. Genau das geht halt nicht immer. Mehr wollte ich eigentlich gar
nicht aufzeigen.
Gruß, Stefan Mettenbrink.
Hallo,
ob die „ausgedachten“ Kennzeichen ins importierende Programm übernommen werden, hängt davon ab, wie gut beim importierenden Programm der Import programmiert wurde. Sofern sich das exportierende Programm bei den „ausgedachten“ Kennzeichen an die Struktur hält, kann das importierende Programm die in der Datei unbekannten Kennzeichen vor dem Import anzeigen und dem Anwender eine Umschlüsselung ermöglichen. Somit gehen die Informationen nicht verloren und der Anwender kann direkt beim Import entscheiden in welche Felder die Informationen aufgenommen werden.
Viele Grüße,
Thomas
Könnte es sein, dass mit GEDCOM7 sich manches verbessert?
Da gibt es unter NAME-TYPE die Variante OTHER, mit der Aufforderung: ‚A value not listed here; should have a PHRASE substructure‘.
Wäre so’was dann für den Transport zwischen verschiedenen Programmen, die GEDCOM7 können, eine funktionierende Lösung oder müßte man auf GEDCOM8 warten … ?
Diese Flexibilität gab es bereits unter GEDCOM 5.5.1.
Dort war es auch möglich, einen beliebigen NAME_TYPE zu verwenden: [ aka | birth | immigrant | maiden | married | „user defined“]
Mit GEDCOM 7 wurde nur „user defined“ durch OTHERS mit dem Sub-Tag PHRASE ersetzt.
Ich persönlich finde die NAME-Substruktur _RUFNAME eh etwas unglücklich, da außer einigen deutschen Genealogieprogrammen kein anderes Programm dies versteht.
Der Rufname ist eine deutsche Besonderheit, um bei mehreren Vornamen „einen“ Vornamen durch Unterstreichung zu kennzeichnen. Genau das möchte ich erreichen. Es gibt Genealogieprogramme (z.B. webtrees), mit denen man die Unterstreichung durch einen zusätzlichen Stern am Ende des entsprechenden Vornamens erreichen kann.
Zum Beispiel Karl August* Friedrich /Mustermann/
Diese Markierung hat den Vorteil, dass beim Datenaustausch mit Programmen, die den Sub-Tag _RUFNAME nicht kennen, die Information über den Rufnamen nicht verloren geht.
Nützliche Informationen zur Dokumentation von Namen im genealogischen Prozess sind im Kapitel 11 des webtrees-Handbuches beschrieben: Webtrees Handbuch/Genealogischer Prozess – GenWiki
Hallo Peter,
die Kennzeichnung durch einen * ist noch unglücklicher, da sie überhaupt nicht normiert ist. Das ist nicht besser als das Voranstellen oder Einrahmen mit Unterstrich oder die Eingabe von nur Großbuchstaben (was andere wieder für den Familiennanmen machen).
Da man auf alle solche Spielarten der Anwender gefasst sein sollte, habe ich in meinem Import die aktivierbare Option, dass alle diese Sonderzeichen / Kennzeichnungen schon beim Import in die von der Gedcom-L abgestimmte Version mit dem Kennzeichen _RUFNAME umgewandelt werden können. Damit ist die Darstellung mit Unterstreichung dann sichergestellt.
Für weitere GEDCOM Versionen wird daran gearbeitet, die Namensdarstellung auf allgemeinere Füsse zu stellen und damit nicht nur das Rufnane-Problem zu erschlagen. Aber das ist im Moment noch Zukunftsmusik für die Forscher, die aktuell Daten austauschen.
Viele Grüße
Albert (Emmerich)