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

https://github.com/FamilySearch/GEDCOM/pull/301#issuecomment-1513403034

[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.