Ahnenblattportal

TL;DR
Can the 'Show main name only' be extended to show/hide preferred surnames (birth names) as well as first names?

For example, I'd like to be able to enter 'Моrgenstern Мортенштерн' as birthame (surname), 'Johann Иван' as first names, and 'Моргенштерн Иван' as main name, and when I enable 'Show main name only', I should see only 'Моргештерн Иван' in the trees and elsewhere.

Hi folks,

Can anyone offer some advice on how to manage multiple names for persons in the database? Here's the scenario:

I have multiple family branches with names in Latin, Hebrew and Cyrillic script. What is the best practice to manage these names so different family trees and displays can be generated for different languages?

For example, I'd like to be able to control displaying only Latin or, Russian, or Hebrew original (or transliterated) names in generating the tree etc.

I played a bit with main name and first name(s) and this is helpful, but the problem is that the surname (birth name) can't be had in multiple variations.

Hello sstef,

Dirk B. who is the developer and maintainer and ... of the software, is working for quite a time on the big step toward full GEDCOM compatiblity. The versions 2.8x and 2.9x already include some new capabilities you can't see on the GUI. In the upcoming version 3.0, there will be support of single fact sources and comments and many other things. You will be able to even define your own fact types (alas, they won't be supported by other genealogy software, if you want to exchange data).

So my advice would be not to (mis-)use the usual names fields to enter the same name in different character sets/alphabets, but to wait for the coming ability of the software to allow multiple field entries: You can set multiple birth dates (if you have differing sources) or multiple names. Of course the software has to know which one to take as the main form, so you have to set a check for that and you won't be able to automatically switch between hebrew, cyrillc and latin export style. But at least your data set would be in a neat state. So, for every person you would have to add a second and third 'name' fact and set the type to 'alternative form' - up to now there isn't a type 'cyrillc form' or 'hebrew form', but maybe Dirk or even the user could add this. I will forward a hint to the beta test group.

Your scenario isn't the one why multiple name entries will be possible in the near future - usually people will have to enter alternative writings of a name with just small differences or totally differing aka names. But why not use it for your purpose? The 'alternative name' fact does contain the full name fields - first name, second name, married name etc.

You have to know just one more thing: the upcoming version will be a paying one. You will only be able to get a free demo version or keep the free 2.98 (which will keep the current capabilities with no self defined or multiple data fields) - or pay 39,- EUR for the full/extended version. As we are in beta test, there is no release date for the moment.

Frido

Hi Frido,

Thanks for the response. Yes, ideally you'd want multiple field entries as you described. The suggested quick fix above just extends the already existing functionality. It still may be useful to implement if it's easy to do - looks like that from outside - while waiting for the paid version, or in case the paid versions doesn't quite deliver for my use case. It is essential to be able to switch quickly between languages for the whole tree.

Anyway, if you do plan for such functionality (multiple field values) I'd think it would be useful to manage alternative names as sets on the person record level, not just as individual fields. That way people can switch between different alphabets quickly by ticking a "name fieldset" (i.e. 'Alternative Names 1' , 2, or 'English', 'Russian' etc.) on the DB level in the View menu.

You could create those fieldsets per person by pressing a button generating all the name fields by copying the values from the first or previously existing set, and associating them with whatever name is given on DB level ('English', 'Hebrew' etc.)

I'd be happy to pay for such feature. At the moment, I can get by with exporting to GEDCOM, doing search/replace on the names via a script (or manually in the editor) and maintaining a GEDCOM per language.

Cheers,
Steve

Sorry, Steve,

I dind't explain everything to the end - just gave hints. In fact, the "alternative names" are a feature within GEDCOM that can be used just out of the box in Ahnenblatt. Other supplementary fields as "Name in cyrillic letters" aren't part of GEDCOM, as I think. If I'm right, there is only a field like (latin) 'transcription' as part of the standard. So I don't know if Dirk is interested in extending his software in that way (beyond GEDCOM). Anyway I left a message to his address in the beta test forum.

By the way, we are writing in a users' forum - maintained by users as part of the software's vivid usability environment, which is a result of an agreement between the software's author and some supporters from 2006. And I'm just a simple user (and beta tester) - maybe a bit enthusiastic about the project.

Frido

Hi Frido, thanks for the answers and appreciate the enthusiasm

It's great that the 'alternative names' can be used OOB in Ahnenblatt - that would sort me out, I think - but where are they located in the person card? I can't find any such field:

Fridolin hat geschrieben:In fact, the "alternative names" are a feature within GEDCOM that can be used just out of the box in Ahnenblatt.

Sorry, I was talking about the upcoming Ahnenblatt 3.0 (beta at the moment). It looks a bit different - at least for those activating the full featured mask.

No, in AB 2.98, there isn't such a feature. In AB 3.0, it will be about this like (see below)

Fridolin hat geschrieben:
Sorry, I was talking about the upcoming Ahnenblatt 3.0 (beta at the moment). It looks a bit different - at least for those activating the full featured mask.

No, in AB 2.98, there isn't such a feature. In AB 3.0, it will be about this like (see below)

Looks good. Any chance I can be involved in beta testing?