Question Some of the Custom gedcom tags that you continue to use cannot be used. help me~

Upgraded to version 2.1 beta.

1. Some of the Custom gedcom tags that you continue to use cannot be used.

In the Facts for new individuals setting
I want to set "Militaty" but I can't. Cannot add INDI:_MILI tag.
Custom Gedcom settings with the INDI:_MILI tag did not exist.

Facts for new families
I want to set "Not married", but I can't add the FAM:_NMR tag.

Select Brother’s Keeper™ in Custom Gedcom Settings to
Although the FAM:_NMR tag is enabled, the previously entered data can be viewed
Input is not possible.

2.add new individuals or new families page setup

In version 2.0, when entering information set in Facts for new individuals or Facts for new families, the input box was not expanded.
In 2.1 the input box is expanded. As in version 2.0, the input box is closed.
I'm curious how to edit the status.

3. When adding a new family from existing individuals
The name type is preset to "Birth Name" by default.
I'd like to find a way to make it blank as before.
In Add individuals, the name type is blank as before.

If you can solve the problem by modifying the specific php file above,
Please tell us the file name and how to edit it.
(I am not a programmer. An example of modifying a specific line in a specific file or an example of adding a specific line would be helpful.)

I really like the new features in webtrees version 2.1.
But the co-workers who are doing data entry together don't want a big change.
So I need a solution Please help.

ramu98 wrote:

Select Brother’s Keeper™ in Custom Gedcom Settings to
Although the FAM:_NMR tag is enabled, the previously entered data can be viewed
Input is not possible.

Yes, most of the CustomTagsXYZ modules currently only configure that the respective tags are displayed, but do not allow them to be edited. The reasoning seems to be that these modules are intended for viewing imported GEDCOM only. I do not agree with this. See the respective discussion at the end of this open issue . In my opinion, each of these modules should make all their custom tags configurable for editing as well.

The release notes for 2.1.0-beta said that the changes to custom tags had not been finished.

Internally, GEDCOM tags have changed from being simple labels ("BAPM" = "Baptism"), into GEDCOM structures - each with its own subtags, editor, validator, display format, etc.

Standard tags

I have created a set of definitions for GEDCOM 5.5.1. In the future, you will be able to swap this for another set of definitions such as GEDCOM 7.0.

GEDCOM allows lots of tags which are infrequently/rarely/never used.
These are marked as "hidden by default".
Hidden fields do not appear on the input form until you click a "show all fields" button.

Some are always hidden by default. e.g. INDI:BIRT:FAMC.
Others are configurable using the control panel. e.g. the LDS tags.

Custom tags

Custom tags are created by modifying the GEDCOM definition data. Definitions can be added, removed or changed.

To add support for a custom field (e.g. "time of birth"), you'd write a line like this:

You'd also need to tell the parent tag that it has a new sub-tag, which can occur either once or not at all.

As with most of the code, there is a module interface to support this.
To add your own custom tags, you just need to create a list of definitions like these.

Managing and configuring custom tags in webtrees

We could simply add definitions for every custom tag that has ever been seen in any GEDCOM file created by any other program.

This way, you could load any GEDCOM file into webtrees, and it would "just work".

The problem is dealing with conflicts. What if two different programs used the same GEDCOM tag for two different things?

So, these defintions are currently grouped into modules - one module for Renuion, Legacy, PAF, PhpGedView, etc.

This seems a sensible way to group them. If you import a GEDCOM created by BrothersKeeper, then you enable the "Brothers Keeper" module.
We could even automate this - if you import a GEDCOM file containing a header containg the line "1 SOUR BROSKEEP", then we enable it automatically.

Also, other modules can create their own specific tags. The research-task module creates the INDI:_TODO tag.

If you are a "GEDCOM purist", and do not want any custom tags to appear in your data, then you just disable all these modules.



Adding custom tags is a little more difficult to manage. You cannot allow every possible custom tag to appear on the input forms.
An example of why this won't work is the "time-of-birth" field. There are lots of them, and you'd have all lots of fields with the same label "Time of birth"

INDI:BIRT:DATE:TIME
INDI:BIRT:DATE:_TIME
INDI:BIRT:DATE:_ALDFAER_TIME
INDI:BIRT:TIME

Another example is INDI:_UPD "Updated" which other applications use instead of INDI:CHAN:DATE / INDI:CHAN:DATE:TIME
It wouldn't make much sense to have two "last change fields with different formats.
And do we want to allow the "INDI:_NMAR Y" as an alternative to "INDI:NMR 0"?

> In my opinion, each of these modules should make all their custom tags configurable for editing as well.

I think the majority of users do not know care about GEDCOM. They just want a genealogy application that works.

How can a user know how to choose to enable INDI:_MEDI or INDI:_MDCL (or use both)?
How can a user know how to choose between "DEAT Y" and "_NLIV Y" (or use both)?

If the configuration options are too overwhelming they will give up.
They will just decide that webtrees is too complicated / doesn't work.

So we cannot simply have a list of every possible subtag with a check-box to enable/disable.

We'll need to add some knowlede/guidance. Either choose for them, or explain how to decide.

I have been searching the web for example GEDCOM files created by various desktop applications.
Each time I find a new one, I need to update the definitions for that module.
We can't build a sensible system for configuring subtags until we know what subtags exist and what they all mean.



Finally - what of webtrees own subtags? Should these be configurable? We allow RESN on all records (not just INDI/FAM). Privacy settings won't work if we disable SOUR:RESN.

친절한 답변 감사드립니다.

Thank you for your kind and detailed reply.
I want to know the php file where I need to apply the custom gedcom tag included in my question. I don't know which of the numerous module files to modify. Please help.

fisharebest wrote:

We'll need to add some knowlede/guidance. Either choose for them, or explain how to decide.
We can't build a sensible system for configuring subtags until we know what subtags exist and what they all mean.

But when will this be ready? In the initial 2.1? As you see, there are already requests for custom tags. I expect many more of this kind.

I don't think this is a realistic approach.

If everything is configurable, most users won't touch it anyway and not get overwhelmed either. The ones that enable some custom module for additional tags may indeed end up with multiple tags like this:

fisharebest wrote:

INDI:BIRT:DATE:TIME
INDI:BIRT:DATE:_TIME
INDI:BIRT:DATE:_ALDFAER_TIME
INDI:BIRT:TIME

For this, we could add a 'debug view' in the respective edit control which shows for each of those tags which custom module is responsible for the tag. Then the user would be able to re-configure the modules properly, until just one of the tags remains.

Do you really rather want to decide this yourself for all kinds of custom tags and their combinations?

Hello Greg,

> I have created a set of definitions for GEDCOM 5.5.1. In the future, you will be able to swap this for another set of definitions such as GEDCOM 7.0.

I think you have to differentiate between standard sets (GEDCOM 5.5.1, GEDCOM 7.0, ...) and custom sets with program specific or module specific tags. Each custom set should have a mandatory relation to one of the standard sets.
The standard set and additional custom sets should be defined for each tree in the preferences.

> The problem is dealing with conflicts.

If more than one custom sets are ticked, the additional tags should be checked for conflicts (two different programs used the same GEDCOM tag for two different things).

For custom tags we need clear rules. Most important rule: Custom tags must not violate the standard.
This means that custom tags with missing leading underscores should be marked as wrong in the forms. Or if a standard tag exists for a custom tag, the custom tag should be marked as well ("DEAT Y" and "_NLIV Y").
In my opinion such rules are mandatory, otherwise webtrees creates GEDCOM files which violate the standard.

Custom tags should be marked in the forms, so that the user see their origin root. E.g. "Time of birth (Aldfaer)".

Peter_S said:

think you have to differentiate between standard sets (GEDCOM 5.5.1, GEDCOM 7.0, ...) and custom sets with program specific or module specific tags. Each custom set should have a mandatory relation to one of the standard sets.
The standard set and additional custom sets should be defined for each tree in the preferences.

The problem with this is that some of the current applications are based in either GEDCOM v5.5 or create "custom tags" that are in different places or cause hierarchical issues with other standard tag sets. You can't just say take all of v5.5.1 and add to it a "custom set" used by FTM or RM8!

The examples Greg gave are real!

Peter_S also said:

For custom tags we need clear rules. Most important rule: Custom tags must not violate the standard.
This means that custom tags with missing leading underscores should be marked as wrong in the forms. Or if a standard tag exists for a custom tag, the custom tag should be marked as well ("DEAT Y" and "_NLIV Y").

Unfortunately not all programs use the "_" to lead all out of place tags. For example some software does not differentiate the use of the ADDR tag that is a subtag to an event/attribute vs the same tag that is its own "fact".

In reality, and a lot of work and wrought with potential errors, is to select an importing schema of tags that include *all* tags for the importing GEDCOM's piece of software. But this then will never push users to embrace Standard GEDCOM and will only be used by people who what webtrees to display on the internet rather than them using webtrees as their genealogy software. the other issues with embracing FTM's, RM*'s and all of the other application's dialects is when we start writing reports that support Standard GEDCOM and then everyone that wants a report to support their dialect that report may not work because the data that controls a function is in the wrong place.

norwegian_sardines wrote:

You can't just say take all of v5.5.1 and add to it a "custom set" used by FTM or RM8!

I guess, that‘s the way it is realized in the current 2.1 beta version.

norwegian_sardines wrote:

The other issues with embracing FTM's, RM*'s and all of the other application's dialects is when we start writing reports that support Standard GEDCOM and then everyone that wants a report to support their dialect that report may not work because the data that controls a function is in the wrong place.

I don't think this will be a problem if we clearly point out when data is displayed in wrong tags, deviating from the standard.

> Custom tags should be marked in the forms, so that the user see their origin root. E.g. "Time of birth (Aldfaer)".

An interesting idea. If you are editing data in webtrees, then this could be useful.
But if you are just using webtrees to display your data, then it is not helpful or necessary.

To be really helpful, we'd need to provide information such as
"_EMPLOY means the same as OCCU - Click here to fix your data"



> I want to set "Militaty" but I can't. Cannot add INDI:_MILI tag.

If we continue with the current system, he would need to know which application created it, so he could enable that module and enable the tag.

But more likely, he won't know which application created it, and will need to try all of them. Not a great user-interface.

Also, there are several applications that create it. If one enables it and one does not enable it, then it will still be enabled.
This may be confusing if he is looking at the configuration for the one that is disabled.

Also, there are similar tags with similar names - _MILI and _MILT. How to know which is which?



> In my opinion, each of these modules should make all their custom tags configurable for editing as well

In my opinion we should only allow a "sensible" custom tags to be added.

If you really want to use "INDI:NLIV Y" instead of "INDI"DEAT Y", then you can always create a module to do it.

> I don't think this will be a problem if we clearly point out when data is displayed in wrong tags, deviating from the standard.

We need to be careful. Many (most?) people don't care about this.
It would need to be an opt-in feature.

For example, one of webtrees most active testers asked me to create a module for her, so she can use INDI:ADDR and many other non-standard tags.
She was using phpGedView since it started, and knows the GEDCOM specification in detail.
She just wants a genealogy application that works for her...

As I see it we have three distinct user groups.

1. Those that use webtrees as their only genealogy application and probably use the v5.5.1 Standard without any or just a few additional tags. Their users may or may not be active entering data.
2. Those that use webtrees just to put their GEDCOM file on the web, they don’t really care about “The Standard” just that they want the GEDCOM their software produced to be properly (with proper titles and all translations) displayed. Their users are probably in view only mode with little updates if any. Their users will probably want to print reports
3. Those users of webtrees that use another program that they like the reporting, but think they want to eventually use webtrees exclusively if the can get similar function from it as they do from their current desktop program. They may be round trippers as well! They need teaching to help them move to webtrees exclusively.


The first group really don’t care about this upgrade, except if they want to move to v7.0 of GEDCOM.

The third group wants to know what needs to be changed going forward if they use webtrees exclusively and probably want reports to work so they can get off their current software.

The 2nd group is what’s driving this change, they want a genealogy GEDCOM viewer, that allows them to not have to think about GEDCOM dialect, but have the display or a report about their family have all titles and translations work. This requires an extensive understanding of the dialect being imported, how their custom tags change the way the GEDCOM Standard works (so that reporting works). This includes the possibility of any linking to other records that are not in the GEDCOM spec but are used to add information about a tag.

The 2nd group kind of includes the _LOC @xxx@ from GEDCOM-L and a close cousin the _PLAC @xxx@ tag that some applications have implemented.

EDIT:

In addition some smart PHP coder could introduce additional dialectical changes as a custom module to fix problems in GEDCOM itself, like doing a better job of storing sourcing information, or a better media handling OBJE record!