Please do NOT expect all Feature Requests to be actioned automatically. Describing your proposal here will ensure the development team are aware of it, and they will give it careful consideration.
  • Page:
  • 1

TOPIC:

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #1

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
I would like to have an admin-selectable option so that adding a new person, instead of creating
1 NAME Hildegarde Ophelia /Hamhocker/
2 GIVN Hildegarde Ophelia
2 SURN Hamhocker
2 _MARNM Wajberlynski
would instead generate
1 NAME Hildegarde Ophelia /Hamhocker/
1 NAME Hildegarde Ophelia /Wajberlynski/
2 TYPE Married
No need to change the entry form; just omit the second name if that field is blank. And if the editor doesn't know the birth name, they could leave that surname field blank and it would create only
1 NAME Hildegarde Ophelia /Wajberlynski/
2 TYPE Married
I always edit the raw GEDCOM to make this change each time. I realize the other stuff has value to some, so I ask for an option, with the default being the current behavior. I already know that webtrees has no problem importing the "pure" format.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #2

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
I would like this too.

See github.com/fisharebest/webtrees/issues/794
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #3

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658

fisharebest wrote: See github.com/fisharebest/webtrees/issues/794

After reading the issue, I would revise my request to (1) make the standard format the default; (2) if standard is selected, do the conversion on import; (3) if the admin selects the FTM form, don’t do the conversion on import, and on “add,” do the current behavior.

(This is just a concession to any current users that like this weird format.)

I also note that in the current behavior, if the married name field is left blank, automatically creates a _MARNM for a female with the main name, but does not do so for a male. These cultural assumptions—that women change their names at marriage, and that men don't—are no longer valid even for English-speaking culture, and have never been valid for many cultures. So that's another reason for shifting to standard.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Last edit: by WGroleau. Reason: Additional rationale.

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #4

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658

WGroleau wrote: I also note that in the current behavior, if the married name field is left blank, automatically creates a _MARNM for a female with the main name, …

It does this when adding an unlinked individual. When adding a new person as daughter, it omits the _MARNM. So not only "sexist" :-) but inconsistently so.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #5

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
I'm pretty sure this is a consequence of the "surname tradition" setting in the control panel.

Try changing it from "Paternal" to "None".
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 10 months ago #6

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658

fisharebest wrote: I'm pretty sure this is a consequence of the "surname tradition" setting in the control panel.

Try changing it from "Paternal" to "None".

Indeed, with "none" selected, a _MARNM is not created by default. But it's still inconsistent in two ways: (1) with "paternal" selected, it only overrides a blank married name for an unlinked female, but not for "add daughter"; and (2) it uses the primary name for the _MARNM (either implying that she did not change her name at marriage, or assuming that the admin put the married name in the primary field).
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 4 months ago #7

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
I made a change to one function that seemed to do what I want, but I only tested it on the Add Wife form shown in the attachment.  Is there another place where it might cause a problem?

The GEDCOM that resulted is what I like:
1 NAME npfx given /spfx surn/ nsfx
2 NICK nick
2 _AKA /aka/
1 NAME npfx given /Schooler/ nsfx
2 TYPE married

Here is the changed version:
/**
     * Assemble the pieces of a newly created name into gedcom
     *
     * @return string
     */
    public static function addNewName()
    {
        global $WT_TREE;

        $gedrec = "\n1 NAME " . Filter::post('NAME');

        $tags = array();

        if (preg_match_all('/(' . WT_REGEX_TAG . ')/', $WT_TREE->getPreference('ADVANCED_NAME_FACTS'), $match)) {
            $tags = array_merge($tags, $match[1]);
        }

        foreach (array_unique($tags) as $tag) {
            $TAG = Filter::post($tag);
            if ($TAG) {
                $gedrec .= "\n2 {$tag} {$TAG}";
            }
        }

        // Paternal and Polish and Lithuanian surname traditions can also create a married name
        $SURNAME_TRADITION = $WT_TREE->getPreference('SURNAME_TRADITION');
        if ($SURNAME_TRADITION === 'paternal' || $SURNAME_TRADITION === 'polish' || $SURNAME_TRADITION === 'lithuanian') {
            $TAG = Filter::post('_MARNM');
            if ($TAG) {
                $gedrec .= "\n1 NAME {$TAG}\n2 TYPE married";
            }
        }

        return $gedrec;
    }
--
Wes Groleau
UniGen.us/
Attachments:

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #8

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658

fisharebest wrote: I would like this too.
See github.com/fisharebest/webtrees/issues/794


Is there a description of how 2.0 works on this point?
(Of course I can find out easily by experimentation.)
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Do you need a web hosting solution for your webtrees site?
If you prefer a host that specialises in webtrees, the following page lists some suppliers able to provide one for you: 

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #9

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
The only significant change in name handling concerns the selection of which name to show.

In webtrees 1.7, the first non-married name was used.
In webtrees 2.0, the first name of any type is used.

If you want someone's married name to be used in charts, etc., then you can now acheieve this by re-ordering the names.

Of course, this means you'll need to use the "1 NAME / 2 TYPE married" structure, rather than "1 NAME / 2 _MARNM".
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #10

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
Is there a place where I can make a change similar to the one I did before? That change was easy to make, but finding where to make it wasn't as easy.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #11

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
That code can be found in /app/Http/Controllers/AbstractEditController.php

However, all code in /app/Http/Controllers should be considered deprecated. It's being migrated to /app/Services and /app/Http/RequestHandlers.

This change is all about code doing just one thing, which makes testing and re-use much easier. For example, you can't use the code to create new names in a batch job - as it is embedded in code to handle an HTTP request.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #12

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658

fisharebest wrote: That code can be found in /app/Http/Controllers/AbstractEditController.php

However, all code in /app/Http/Controllers should be considered deprecated. It's being migrated to /app/Services and /app/Http/RequestHandlers.

This change is all about code doing just one thing, which makes testing and re-use much easier. For example, you can't use the code to create new names in a batch job - as it is embedded in code to handle an HTTP request.


Previously, I used code that twice called Filter::post. Is that still usable?
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #13

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
> Previously, I used code that twice called Filter::post. Is that still usable?

Not any more. That function was effectively accessing global data - which we are trying hard to avoid.
All processing should be done on the basis of inputs to each function.

We pass in the "request" which contains all the parameters (GET and POST).

The equivalent of
Filter::post('var_name', $default)
is
$request->getParsedBody()['var'] ?? $default

e.g. github.com/fisharebest/webtrees/blob/mas...tController.php#L397
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Last edit: by fisharebest.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #14

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
So
$TAG = Filter::post($tag);
 $TAG = Filter::post('_MARNM');
should be
$TAG = $request->getParsedBody()[$tag]          ?? $default
 $TAG = $request->getParsedBody()[''_MARNM'] ?? $default
?
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 1 year 3 months ago #15

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
If you aren't using the second parameter to post(), then you don't need the '?? $default'
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 4 months 2 weeks ago #16

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
I see in bug reports that _MARNM was changed in 2.0.0. Are all my records automatically converted?

How about GIVN & SURN (etc.)?
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 4 months 2 weeks ago #17

  • eh215
  • eh215's Avatar
  • Offline
  • Junior Member
  • Junior Member
  • Posts: 234

I see in bug reports that _MARNM was changed in 2.0.0. Are all my records automatically converted?

How about GIVN & SURN (etc.)?



Not automatically converted, but....


Control panel --> Manage family trees --> Data fixes --> Convert NAME:_XXX tags to GEDCOM 5.5.1
behunt.net/ft
PHP 7.4.16

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 4 months 2 weeks ago #18

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
[quote="eh215" post=81777
Not automatically converted, but....

Control panel --> Manage family trees --> Data fixes --> Convert NAME:_XXX tags to GEDCOM 5.5.1[/quote]

OK, that works, but now I must reiterate my original request:
That I be able to have web trees STOP creating the non-standard form and make me run the fix repeatedly.

And my related request, to allow me to stop the creation of the standard but completely unnecessary GIVN/SURN/NPFX/NSFX. Not as good but tolerable would be a data fix to remove them.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

Last edit: by WGroleau.

Purist doesn't like SURN/GIVN/_MARNM 4 months 2 weeks ago #19

  • fisharebest
  • fisharebest's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 14403
this has mostly been written. it is in the develop branch on github. will probably become 2.1
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Purist doesn't like SURN/GIVN/_MARNM 4 months 2 weeks ago #20

  • WGroleau
  • WGroleau's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
  • Posts: 1658
Looking forward to it. I see (with disapproval) that the 5.5.5 folks want to make that clutter mandatory.
--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

  • Page:
  • 1
Powered by Kunena Forum