Feature Proposal: If a fact/events contains a TYPE, show TYPE label instead of label of fact/event

[Jefferson49]

In a discussion in the webtrees forum, Confirmation - German Translation, the following feature was proposed:

If a fact/events contains a TYPE, the fact/event view should show the TYPE label instead of the fact/event label.

This feature is already implemented for some GEDCOM structures:
github.com/fisharebest/webtrees/blob/9fd...p/Fact.php#L452-L460
github.com/fisharebest/webtrees/blob/9fd...s/fact.phtml#L67-L71

E.g., the following GEDCOM code is already handled accordingly.

1 MARR
2 TYPE Not married

1 EVEN
2 TYPE Military Service

One approach could be that the existing implementation could be generalized for all tag combinations INDI:*:TYPE

To give some room for individual likings of the users, it might be helpful to also add some preferences to the control panel. Maybe, something like the attached image, where FACT/EVEN could be used as default values:

[fisharebest]

Even if we make this completely-configurable, we will still need default values for which tags have this feature and which do not.

[Jefferson49]

Even if we make this completely-configurable, we will still need default values for which tags have this feature and which do not.

Yes, I agree. My proposal would be that INDI:EVEN:TYPE and INDI:FACT:TYPE should be used as a default. This would match the currently available implementation, which already shows types in these cases.

For me personally, configuration is just and add on option. We could also consider a 2 step approach. In a first step, we could start without any configuration and show the type label for all facts/events. If there is some critical feedback from the users, we could add some configuration in a second step.

[Norwegian-Sardines]

Not all “facts” end their descriptive path with the TYPE tag!

For example:

1 EDUC Masters of Business Administration
2 TYPE University of …

1 DNA R1
2 TYPE Y-DNA

Before this is put into action, please read my suggestion for GEDCOM v7.0.x

FamilySearch/GEDCOM#301 (comment)

[fisharebest]

For most (all?) of our TYPE fields, the translation is lowercase, so that it can be used in a Label: value string such as Type: foo.

e.g.

1 NAME xxx
2 TYPE married name

becomes in spanish

Nombre: xxx
Tipo: nombre de casado

Thus we can't use it directly as the label. It would need to be "Nombre de casado" instead of "nombre de casado".

[Jefferson49]

the translation is lowercase, so that it can be used in a Label: value string such as Type: foo

Yes, this is an issue for the name types from the NameType class, which are currently in lower case.

I am not an English or Spanish native speaker, but would it be wrong if they start with an upper case anyway? For me, Type: Foo looks acceptable. And birth name starting with an upper case in the name view might be o.k:

However, one big disadvantage would be that all the translation would need to be changed as well. Probably difficult to organize.

I also checked the MarriageType class. The 3 included types start with an upper case.

I also tried to identify other Type classes in the \Elements folder (see screenshot below). It looks like they might not be that relevant. However, it would also need a decision how to proceed with these types. My feeling would be to limit the label issue to INDI:*:TYPE and FAM:MARR:TYPE.

[Norwegian-Sardines]

In GEDCOM v7.0.x, all TYPE enumerations are all uppercase! At some point in the future this will need attention. Is it possible for a future release to have translations for TYPE to have multiple options? For example: INDI.NAME.TYPE = “MARRIED”, translates to (sentence case) “Married”, (lower case) “married”.

For multi-word enumerations (AKA) we would maybe need to eliminate(sentence case) and call it (title case) translate to “Also Known As”.

Just some thoughts.