YAML custom types revisited

Ideas
1

I wrote something similar in another thread about TAGs, but the same idea applies here in the discussion about event types:

Instead of expanding a static, hard‑coded list of default types — which will never cover all cultural, historical, or methodological needs — Gramps could move toward a more flexible solution by allowing users to import vocabularies.

A simple “import type list” feature, or the ability to read type definitions from something like YAML, would let users adopt standardized sets that actually match their workflow and cultural context. This avoids bloating the application with long predefined lists, while still giving everyone the ability to use the types that matter in their own region, tradition, or research domain.

This could also include the types that Gramps relies on internally for its algorithms, such as Birth, Death, Marriage, etc. These “system‑critical” types could easily be marked in the YAML vocabulary using a dedicated property, so Gramps knows which types have special behavior. That way we keep full flexibility without losing any core functionality.

The same mechanism could be used for tag sets, attribute lists, relationship types, and place‑naming conventions. Instead of hardcoding more and more variants, Gramps could offer a way to reuse and share vocabularies across databases — including established open vocabularies from the broader humanities and cultural‑heritage domain.

And this whole discussion also mirrors the situation with RSC and CSL support or the Place Hierarchy list handeling discussion we had a few years back: the same principle applies — instead of hardcoded fields, Gramps could dynamically read external vocabularies and standards, rather than reinventing the wheel each time.

PS: YAML is just an example, but it is human‑readable, easy to parse, and supports hierarchical structures, which makes it much easier to create correct files manually.

2

How are such flexible vocabularies translated into 50 or more languages?

3

This has my 100% support after having spent some considerable time modifying the eventtype.py file to my own satisfaction to have to repeatedly do it with every upgrade will become a real chore.

Birth, Joining(Marriage), Death are the only essentials all the rest depend on cultural or personal choices and should added as required by the individual.

phil

4

It’s actually quite straightforward: a flexible, user‑defined vocabulary doesn’t need translation at all.

Users create vocabularies in the language they work in, based on the terms they actually use — so the vocabulary is already in the user’s own language. No translation layer is required.

And if someone wants to use an existing open vocabulary, most of those most likely already exist in the language the user needs, or have translations available.

If translation were desired, it could easily be handled as a simple key/value property in the YAML vocabulary itself, for example:

Kode

en: married
no: gift
se: gift

But no other custom lists in Gramps are translated today, so there is no reason this one would need translation either.
If someone wanted to create a fully translated example vocabulary covering all languages, that would also be trivial — but it’s not required for normal use.

5

This is only true if you are the only one user. This is your “normal” use. If you like to exchange information with others using a different language you have to translate.

For example if you are using Gramps Web there are several users speaking eventually different languages. Then there is a need for translation. Or if you like to exchange information with other researchers.

6

This is just another strawman.
Gramps currently has only one system language, and that is what is used regardless of who you share data with.

User‑defined types and lists have never been translated.
That applies to event types, relationship types, place types, source types, attributes, and anything else a user can add. Making the system more flexible does not change this.

If a user wants their vocabulary to be usable in another language, they can simply create a set of lists that include alternative language variants, or point to an existing standardized open vocabulary that already exists in the language the recipient uses. That is entirely up to the user, exactly as it is today.

And if someone does want translations, they can easily add them as simple key/value pairs in YAML, with a key for the system name and the default language label, for example:

en:
  label: married
  system: yes

no:
  label: gift
  default: yes

se:
  label: gift

This way a user can actually use very local terms for types, and with one single key describe it with the correct term in another language — for example a Norwegian dialect word, plus the English and Norwegian Bokmål terms, as well as Danish and Swedish labels for their Scandinavian cousins.
Today, this is simply not possible in Gramps.

But again: Gramps has never translated custom lists, and there is no reason this would suddenly be required.

As an example from this discussion: Separated is simply a user‑defined type meaning “no longer in a relationship”. It has no system‑critical function in Gramps.

Only a very small number of system‑critical types are used internally by Gramps.
Everything else users ask to add is effectively a custom type, even if it is currently hardcoded into the standard lists.

As mentioned earlier, a simple key can define whether a type has an internal system role, by specifying the English system identifier. Everything else is user‑specific terminology, exactly as in today’s Gramps.

With a system like this, it would also be easy to define multiple terms for system‑critical functions in Gramps. For example, consider the discussion some time ago about stillbirths and how they should be handled in Gramps.

If a user has very specific situation‑critical types, they could simply mark them with a key indicating that these should act as alternatives to, for example, Death.
A user could define that Urn Interment should be treated as a death marker, and Gramps could automatically apply the correct logic — such as interpreting it as “sometime before this date” when calculating age or other system functions.

Today, this is not possible without modifying Gramps itself.

The essence in this is:
The only thing a hardcoded list does is add more items that only a small subset of users actually need.
Most of the types users ask to have added as “standard” in Gramps are not about translation at all — they are about convenience and about being able to reuse the same lists across multiple databases.

7

Appreciate the passionate defense of the status quo. “It’s never been translated, therefore it never needs to be” is certainly an argument.

By that logic we’d still be hardcoding everything in English and calling it a feature. The YAML idea is actually reasonable - thanks for eventually arriving, several paragraphs later, at describing a translation mechanism for user-defined types while insisting the problem doesn’t exist.

8

Well put. The difference is that the Custom Types is a “workaround”. They are to cover situation the Developers hadn’t considered or considered too much of a niche to “build in”.

However when a “system” design is proposed, it needs to consider multilingual needs, GUI, consistency with existing systems, error handling, internal and external documentation. That tends to be aggravating and fussy. And it tends to massively expand the code and design hours.

9

Further, this has deviated wildly from the original intent of my request, which was simply the addition of new types of union, which has been approached and seems to be in the process of being implemented.

Translations I am sure can come with time, but for now the base line needs to be established before the layers can be added onto.

@emyoulation as I think my question got lost in this translation discussion; have betrothals been considered for addition (to represent arranged unions not by the marital pair, in comparison to an engagement, which is by the pair), or are they going to be folded into engaged/be a custom type per user needs?

10

More strawmen.

The only reason I even mentioned translation was because you introduced it.
My point has never been “it’s never been translated, therefore it never needs to be”.
My point is simply that Gramps has never had a translation mechanism for user‑defined types, and a flexible vocabulary system does not suddenly require one.

Please don’t put words in my mouth.

11

You’re describing challenges that apply to any system design — but none of them actually change when moving from hardcoded lists to a flexible vocabulary system.

Gramps already has:

  • one system language (English)

  • a fixed set of system‑critical types

  • user‑defined labels for everything else

  • GUI handling for custom types

  • documentation for custom types

  • error handling for custom types

A flexible vocabulary system doesn’t add new multilingual requirements, new GUI complexity, or new internal logic. It simply externalizes what is currently hardcoded, without changing how Gramps works.

In other words:
nothing becomes more complicated — it just becomes more flexible.