Surnames + 'Toponymic' as a Name Origin Category Instead of 'Feudal'

Hello all. Thanks for this excellent software. I’ve just started using it and have run into some cultural names-related issue which I hoping people have suggestion for, and I have one suggestion regarding "

No Surnames

I’m from Tamil Nadu in India. Naming conventions vary widely here. But very often names contain the following components:

  1. Village/Town name
  2. Father’s given name
  3. Person’s given name
  4. Possibly, caste.

Components 1 and 2 are often displayed as initials. So the name Manur Swaminathan Prakash (villageName-fathersName-givenName) would normally be written as “M.S. Prakash”.

If a caste name is not used (it is quite uncommon in Tamil Nadu in the 100 years or so), then there is no real ‘family name’ that indicates one’s family whether patrilineal or matrilineal lineage.

Apart from the above 4 name parts, there may also be a religious given name (which may be different from the person’s given name) which may be used during religious ceremonies alone. But this can be stored with an additional name entry, as can the nickname, if any.

Toponymic vs. Feudal

The second issue is the “Name Origin” field. Why is “Feudal” — a very Eurocentric field — an option when the more general “Toponymic” would work better to cover more cultures and more types of names. Importantly, “Toponymic” should also be an option in the “Display Names Editor”. Currently, to approximate the correct order I have to do “Rest Patronymic Given” after making Patronymic the “Primary surname”.

Initials for Family Names as Well

It would also be great if “Initials” in the Display Names Editor could generate the first letters of any part of a name (as a function with variable inputs), rather than just the initials of the given name. This would cover the South Indian Tamil case as well as covering other cases.

2 Likes

Welcome. A couple of your questions are outside my experience. So I’ll leave them for others to answer.

You can add a custom type to the Origin pop-up menu choices.

Alternatively, you could use the translation tool Weblate to change “Feudal” in your local language dictionary to that less Eurocentric term. This might be more effective since any report that used “Feudal” would also change.

Thanks for the suggestion. I had already added “Toponymic” as a custom type. But I hadn’t thought about the translation option. My suggestion really was to make “Toponymic” part of the default English version (in place of “Feudal”), and then to make it available for selection from the “Display Names Editor” as well.

Currently, only a subset of the default name types are available in the Display Names Editor, and custom types are not.

1 Like

Nice catch! Sounds like a bug to be reported.

I just ran a test here, and we have Location as a type for the name origin. And as far as I can check, Topos is Greek for Location, so the option is already there.

1 Like

Thanks for the correction, @ennoborg. Yes, “toponymic” is “location-name-based”.

I’d used “Location” as well. But I thought (wrongly) that it was a custom type that I had created when previously tinkering with Gramps.

I went to the wiki to check what the in-built options were, and it didn’t mention “location” among them. But I just check the source code, and yes, “Location” is an in-built option.

At any rate, “Location” isn’t an option I can use in the “Display Names Editor”. So I feel that ought to be added.

When I look at the wiki, there are more types missing, but there is a “Rest” category. Have you tried that?

https://gramps-project.org/wiki/index.php/Gramps_5.1_Wiki_Manual_-_Settings#Display_Name_Editor

I had the same thought about Location (Locatie in Dutch), that it was a custom type, but I found that its name changed when I ran Gramps in English.

From what I read in the source code, custom types can’t be used in any editor because they all map to the same built-in type CUSTOM!

A type is a t-uple (built-in type, string). Built-in types are completely defined by their code and don’t need any qualifying string as (built-in type, ‘’). On the contrary, custom types are (CUSTOM, string). And the string is not stored in any global “dictionary”. The string is duplicated in any record using it.

This design choice precludes any “smart” management. You can’t associate any descriptor to a custom “type” because the only possible would be %CUSTOM (or something like that) and it would match independently from string.

I am presently thinking about it to devise a solution (but it would cause a possible incompatibility with existing trees; incompatibility which could be solved by backing up a tree and reloading it).

3 Likes