Bienvenue, Invité
Nom d'utilisateur : Mot de passe :
Before asking for help please read "How to request help" by clicking on that tab above here.
  • Page :
  • 1

SUJET :

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #1

  • norwegian_sardines
  • Portrait de norwegian_sardines Auteur du sujet
  • Hors Ligne
  • Gold
  • Gold
  • Messages : 1630
Recent changes to the display of the NICK sub-tag as part of the Name-Structure presents me with a dilemma that I wanted to discuss.

First let me present you with a little historical background.

Back in the day before computers (and in particular “personal computers” on everyone’s desk) myself and many of the genealogists I mentored with used either handwritten or typed (with a typewriter) genealogy documents. When recording a name, we used the following conventions. First, we would write the person’s full name, including all given, middle, and surnames. If the individual had a primary nickname that was also include. (Some people had multiple nicknames which was up to the recording individual to include or not).

The standard at that time was:
  1. Given Name(s)
  2. Nickname, encased in quotations
  3. Middle Name(s)
  4. Surname, all capital letters.

The assumption was that the given name, unless a nickname was included, that this was the primary “Call Name” for that individual. For example: Johann Ludwig Casparsen Feyling, had two given names (Johann Ludwig) a middle name and a Surname.

He could be recorded as:
Johann Ludwig Casparsen FEYLING

However, because he actually went by Ludwig we would actually record the name as:
Johann Ludwig* Casparsen FEYLING
With an asterisk following the name because with a typewriter we could use the “*” to designate this as his “Call Name” or “Preferred Name”. Later when it was easier to backspace with a typewriter, we tended to underline the “Preferred Name” so it stood out better.

Later with standardized forms and then GEDCOM we had fields to enter the various parts of the name so that recorders could tell readers how the various parts of a name were used. Thus, we got in GEDCOM a tag for NICKname. A preferred name that was part of the official name never received a field/tag in my mind because one needed to record the actual full name and the asterisk was still part of the understood standard. If people saw a value in the nickname filed that knew that some people used that name to identify the person.

Current Status in webtrees.

In the past I have recorded an individual’s name using the history of recording that I learned and practiced for years.
Entering the official full name with all given, middle and surnames, marking all cases where a preferred name was known. Since phpGEDView took the supplied nickname and placed it between the first name and all subsequent names encased with quotes when data was displayed, I never needed to enter that in the NAME tag.

So…
1 NAME Eugene Marion /Sutter/ Jr.
2 NICK Junior

Was displayed as Eugene “Junior” Marion Sutter Jr.

This worked fine. In lists I could find “Junior” quickly because his nickname was included in the name display, and different than his father and son due to the nickname. I could search on “Junior” because the data was in a tag of its own.
With the change recently made to code in webtrees, the nickname is no longer included in the display name. I understand the reasoning here and this is not in dispute. However, nicknames are now taking a back seat to identifying an individual in displays of a name.

My Dilemma

How do I record nicknames for search and display benefit?
  1. I would be willing to enter an additional NAME tag for all nicknames, but we do not have a name TYPE for “nickname”.
  2. I would be willing to enter the nickname as part of the NAME tag, but now I need to enter it twice so that I can both ‘see’ the nickname in lists but also search on the nickname as an independent tag.
  3. I’d be willing to create a separate NAME tag for “Nickname” so that the additional name is listed in any lists and searchable as a name (rather than using the nickname tag of the primary name) but:
    a) no TYPE for nickname is included in the dropdown (use aka?) ,
    b) the nickname tag is still available for recorders as part of the primary name to (against my standard) enter the nickname here rather than as a separate name entry.
So… there you have my dilemma. How, within the current use state of webtrees do I enter a nickname, so that a) it is searchable, b) displayable in lists, c) eliminates double entry, d) eliminates confusion for where to enter.
Ken

Connexion ou Créer un compte pour participer à la conversation.

Dernière édition: par norwegian_sardines.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #2

Hello Ken,

I'm strugling with the same dilemma. As you are the GEDCOM-expert: isn't it so, that in 5.5.1 we have the sub-tag NICK?

1 NAME

GIVN
SURN
NPFX
SPFX
NSFX
NICK
NOTE
SOUR

So, I don't understand the reason for not using NICK in webtrees? As in western cultures the standard still is

1 NAME NPFX GIVN NICK /SPFX SURN/ NSFX

For other cultures, IMHO, the best way should be to implement the user-option to change the order of displaying the sub-tags.

Lars
genealogie-ravenswaaij.online published by webtrees 2.06 on debian 10.4 with nginx 1.19, php 7.4 and mariadb 10.5

Connexion ou Créer un compte pour participer à la conversation.

Dernière édition: par Lars1963.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #3

  • norwegian_sardines
  • Portrait de norwegian_sardines Auteur du sujet
  • Hors Ligne
  • Gold
  • Gold
  • Messages : 1630
Lars,

One of the issues today with adding the nickname automatically to the display name is “where to insert the name”. This is, I think, the reason it was not automatically added with a resent update.

I’m not an expert on all cultures so I can’t give examples, but in my case I can say I have two different potential outputs for “my culture”.

People with two given names vs people with one given name. John Robert Nickolas Smith has two “given names”. Maybe John Robert should be hyphenated “John-Robert” but my records don’t indicate that, but he was called John Robert as a given name rather than John as a given name.

So where does the software always insert the nickname?

After the first entered name? This is correct for single given names but not for multiple given names.

Then what about cultures that reverse name orders or where in Genealogical terms the nickname is always displayed at the end of the written name? I can’t answer this because it is beyond my understanding of those cultures.

As far as the NICK tag, using it is fine, but as I think I indicated, using it does not solve the name display issue for families where there as multiple individuals with the same given name and surname and the nickname or preferred name are the only way to find the right individual in a list of people.

The problem with user defined order is that, as we all expand our family histories we very often cross cultures, It is easy if all of my family was Nordic, but I’ve now recorded Hungarian, Polish, Brazilian, Spanish, Korean and other naming cultural groups into my “family”. One size (naming rule) will not be adequate going forward.
Ken

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #4

I have come around to the view that the best option is indeed to manually include the nickname in the main name, with full control over the position. It is still useful to have it in the NICK tag as well.

However, if you have lots of nicknames and do not want to convert the respective names manually (a data fix would be helpful here), AND if you mainly want most nicknames to be displayed right in front of the surname, as in webtrees 1.x – there is an option for this in my custom module "Classic Look & Feel".
Richard

webtrees 2.0.6 at cissee.de/webtrees2
Vesta custom modules (Classic Look & Feel, Gov4Webtrees, Shared Places, Extended Relationships) available at cissee.de

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #5

@Ken

OK. I see the problem now and I must agree with you.

@ric2015

Correct me if I'm wrong, but afaik directly using "" or * in the NAME-tag is not the GEDCOM-standard.
So directly doing something like

Jacobus "Cobes"/ van Ravenzwaaij/ Sr

in webtrees name field could possibly be a problem?
genealogie-ravenswaaij.online published by webtrees 2.06 on debian 10.4 with nginx 1.19, php 7.4 and mariadb 10.5

Connexion ou Créer un compte pour participer à la conversation.

Dernière édition: par Lars1963.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #6

Lars1963 écrit: afaik directly using "" or * in the NAME-tag is not the GEDCOM-standard.


Strictly that's true. The current Gedcom specification 5.5.1 states "Removed the convention of specifying a nickname in double quotes." (It could still be argued that it's not explicitly disallowed to handle nicknames in this manner)

Anyway, these conventions are explicitly supported by webtrees: See e.g. here (there are several other forum threads) for related discussion.
Richard

webtrees 2.0.6 at cissee.de/webtrees2
Vesta custom modules (Classic Look & Feel, Gov4Webtrees, Shared Places, Extended Relationships) available at cissee.de

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #7

  • norwegian_sardines
  • Portrait de norwegian_sardines Auteur du sujet
  • Hors Ligne
  • Gold
  • Gold
  • Messages : 1630
This here is where, GEDCOM data and displaying of the data are divergent. It is one thing to appropriately store the nickname in the NICK tag/field but another thing to display and search for the value. This is also an issue with what old time genealogists like myself expect to see and have recorded in the past.

webtrees does allow searching for nicknames in the Advanced search, by going down to the “Add more fields” and selecting Nick Names, this is great!

Display in the resulting list does not show the nickname because it is not present in the NAME tag. Greg has indicated that a data-fix could be created to copy the value of NICK to the NAME. This works, but would need to be run periodically to fix new individuals added without the dual entry (NICK and NAME tags). Not a big deal to do, but less than optimum.

Right now the asterisk following the preferred name has no field to do searches on so a general name search is the only solution and I’m ok with that because the preferred name is displayed in lists and if someone created a AKA NAME entry rather than using the asterisk the name would be searchable and listed in search results.

So the dilemma of standardized data entry would be to enter the nickname in the NICK field, -AND- either add it manually to the NAME tag or create an additional AKA NAME tag with the nickname spelled out so result lists display the name.
Ken

Connexion ou Créer un compte pour participer à la conversation.

Dernière édition: par norwegian_sardines.

The Nickname Dilemma – A Discussion il y a 1 semaine 6 jours #8

norwegian_sardines écrit: So the dilemma of standardized data entry would be to enter the nickname in the NICK field, -AND- either add it manually to the NAME tag


All other name parts are added automatically to the name tag on data entry, as long as the name has a standard structure (i.e. has not been modified manually).

Maybe this should be done for the nickname (NICK field) as well, based on a tree preference indicating its default position? In specific cases, the name will have to be adjusted manually in order to move the nickname elsewhere, but if most names follow a specific structure (such as 'nickname before surname'), this should result in less work on data entry, while preserving full flexibility.
Richard

webtrees 2.0.6 at cissee.de/webtrees2
Vesta custom modules (Classic Look & Feel, Gov4Webtrees, Shared Places, Extended Relationships) available at cissee.de

Connexion ou Créer un compte pour participer à la conversation.

Avez-vous besoin d'une solution d'hébergement web pour votre site webtrees ?
Si vous préférez un hébergeur spécialisé de webtrees, la page suivante en liste quelques-uns capables de vous offrir ce type de service :

The Nickname Dilemma – A Discussion il y a 1 semaine 5 jours #9

  • fisharebest
  • Portrait de fisharebest
  • Hors Ligne
  • Administrator
  • Administrator
  • Messages : 13196
> as long as the name has a standard structure

We already have many standard structures:

Default (european/US)
Patronyms
Surname first
Surname first without spaces
Polish surname inflections

We choose a structure according to the current language.

If your site contains mostly data from the same culture/language, then this works OK.
If your site contains names from many cultures, then it can create more work than it saves.


But "inserting nicknames" is possibly a solution to the wrong problem...

I know that people use NICK to store name parts that are not part of standard "western" naming system. e.g. arabic and asian names.


I once tried to create the reverse system. You entered the "NAME" field using GEDCOM format, and webtrees extracted parts into the other fields. I don't know if this is too much of a change from the current system.
Greg Roach - Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. - fisharebest.webtrees.net

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 5 jours #10

  • norwegian_sardines
  • Portrait de norwegian_sardines Auteur du sujet
  • Hors Ligne
  • Gold
  • Gold
  • Messages : 1630

But "inserting nicknames" is possibly a solution to the wrong problem...

You are right in my case, in that, I don’t really need to use the NICK tag at all because I do see this as a potential new NAME with a nickname (or aka) TYPE. Thus giving me what I want, exposure of the nickname in general and search lists.

The downside to this as a standard is that a) the NICK tag is always enterable when adding a new individual (breaking my standard), b) imported GEDCOM always uses the NICK tag and would require massaging to my standard.

I can deal with b) because I don’t import/merge from outside GEDCOM, But a) presents a problem unless I review all entries and create a new NAME from the NICK just like I would for the married name sub-tag of the NAME.

I would need to remove these from the data entry NAME screen!
Ken

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 5 jours #11

  • fisharebest
  • Portrait de fisharebest
  • Hors Ligne
  • Administrator
  • Administrator
  • Messages : 13196
> I would need to remove these from the data entry NAME screen!

This should be possible in 2.1.0

GEDCOM tags and structures are now defined in a "GEDCOM definition module".

It means that all valid GEDCOM 5.5.1 tags are now available for all facts/events/records.
This includes all the ones that people rarely use.
e.g NAME:FONE:GIVN, PLAC:ROMN:TYPE, etc.

I am still trying to work out the best way to configure all this.

Tags are defined by modules (and hence globally available), so do we want to configure them globally - or by tree?

Also, the current system allows you to select tags to include (e.g. "Advanced place facts").
But since modules can define/add tags, it seems better to select tags to exclude.

e.g. "Don't show NAME:FONE, PLAC:ROMN, BIRT:DATE:TIME", etc.

Also, what tags should be included/excluded by default?
Greg Roach - Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. - fisharebest.webtrees.net

Connexion ou Créer un compte pour participer à la conversation.

The Nickname Dilemma – A Discussion il y a 1 semaine 4 jours #12

  • norwegian_sardines
  • Portrait de norwegian_sardines Auteur du sujet
  • Hors Ligne
  • Gold
  • Gold
  • Messages : 1630
Q: Tags are defined by modules (and hence globally available), so do we want to configure them globally - or by tree?
A: In my world where I could be creating temporary trees for people I work with tracing their genealogy, done exclusively on my personal server, I would rather this be configured by tree. However, I could see where some trees share the same configuration maybe from a “basic” or every tree gets these and either inherit from that list/config or completely change the config for each tree created. I suppose this way security/visibility of some tags could be defined by sign in type (visitor, editor, moderator, admin), but that may get out of scope.

Q: Also, the current system allows you to select tags to include (e.g. "Advanced place facts").
But since modules can define/add tags, it seems better to select tags to exclude.
A: For me having a “deselection” is best because I am always going to RAW GEDCOM to add tags not supported in the data entry forms. BUT… Many round-trippers are coming from environments that do not even support what I think are basic GEDCOM tags (i.e. TYPE, ADOP->FAMC->ADOP, Except/Don’t Except EVENT-STRUCTURE-“Description” or BIRT/DEAT “Y”), therefore they may not want to see or have available for their users a lot of “useless tags”. It may be too much to ask for but at tree creation maybe a selection from say “minimal tags” (Facts only have Date, Place, NOTE, SOUR) or “robust tags” (all GEDCOM tags) as the default. Then an administrator can add or subtract from those starting points.

Q: Also, what tags should be included/excluded by default?
A: From a minimalist standpoint (my take, I know I will have a lot or argument):
1)Individual FACTS (Events and Attributes) 
	a.	should start with:  DATE, PLAC, NOTE, SOUR, RESN, OBJE
	b.	optional: ADDR, ASSO, TYPE AGNC, CAUS, 
2)FAMC Only
	a.	Optional: PEDI, STAT, NOTE
3)Family FACTS 
	a.	I am not sure how many actually use the HUSB->AGE or WIFE->AGE
	b.	I am not sure that we should encourage RESI?  I would remove it but that may be a bit too much for some admins
4)LDS Ordinances
	a.	All On (with all sub-tags also “On”)
	b.	All Off
5)OBJE (Multimedia_Link)
	a.	OBJE XREF Default
	b.	OBJE data structure Off
6)NOTE (NOTE_Structure)
	a.	NOTE XREF Default
	b.	NOTE data structure Off
7)Personal_Name_Structure
	a.	Default: TYPE, Personal_Name_Pieces (Prepopulate with “birth”?)
	b.	Configurable for all others: FONE, ROMN and sub-tags
8)Personal_Name_Pieces
	a.	Default All On (NPFX, GIVN, NICK, SPFX, SURN, NSFX, NOTE, SOUR)
	b.	Configurable to remove anything. (I am not a fan of the wide use of Prefix, nick)
9)Place_Structure
	a.	Default:  PLAC, NOTE only
	b.	Configurable for all others: FONE, ROMN and sub-tags (MAP.. How many use this and is it useful to webtrees?)
10)Source_Citation 
	a.	XREF as Default
		i.	Default: PAGE, OBJE, NOTE, QUAY
		ii.	Configuable for EVEN, DATA and sub-tags
	b.	Data Structure, off but all sub-tags available
11)Source_REPO_Citation (All tags default)
12)Individual FAMS
	a.	Default XREF only
	b.	Configurable to add NOTEs
13)OTHER RECORDs,  SOUR, OBJE, REPO, NOTE Should expose all Primary and sub-tags.

NOTE: at this point I am not a fan of adding “_” new tags into webtrees, only because most admins and applications have not explored the full use of all current tags. BUT…. I would like to see some kind of data-dictionary that can be used to define incoming (imported) GEDCOM files that misuse these “_” tags so that _MILT can be displayed with the word “Military” (almost like a word translator for “_” custom facts).
Ken

Connexion ou Créer un compte pour participer à la conversation.

Dernière édition: par norwegian_sardines.
  • Page :
  • 1
Propulsé par Kunena