Add more 'parts/fields' to the name

Created on 20 March 2023, over 1 year ago
Updated 10 December 2023, 11 months ago

Problem/Motivation

Many times, we need more granular control on the name fields/parts.

Fields: nickname, prefix are used many times here.

✨ Feature request
Status

Active

Component

Code

Created by

πŸ‡§πŸ‡­Bahrain smhar

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @smhar
  • πŸ‡¦πŸ‡ΊAustralia Alan D.

    Have you tried making a new name format using the preferred or nickname option (p) then setting up the formattor to use this? The p option falls back to the given or first name. Using q will be blank if the preferred or nickname is blank (i.e. no fallback).

    By prefix, I assume the title or honorific prefix field? Similar, use the title token (t). There is no fallback option for this token.

  • πŸ‡§πŸ‡­Bahrain smhar

    Name formatting will not work as it is using data from exisitng fields.
    Nickname is not initials. It may be totally not related to the name. It is something like.. 'father of ...' , so it varies and need to be its own field.

    Prefix is usually a one or two letters. And it is a list of two or three options only.

    Not all names have nicknames, and not all names have a prefix part.

  • πŸ‡¦πŸ‡ΊAustralia Alan D.

    Probably outside of the scope of the module.

    I'll leave it open in case any of the other maintainers have any ideas but feels like a bit of custom coding could be required.

  • πŸ‡ΊπŸ‡ΈUnited States dave reid Nebraska USA

    I would also like to see a "Preferred" subfield given that our SSO integration where we sync the given and family names are often the legal names, and not what someone would prefer to be called as a first name. For example, Dave vs David.

  • πŸ‡¦πŸ‡ΊAustralia Alan D.

    @Dave The module should have options for linking alternative and preferred fields that can then be used in the display tokens

    Preferred component source

    A data source to use as the preferred given name within the name formats. A common use-case would be for a users nickname.

    Used by the following tokens

    p: Preferred name, use given name if not set.
    q: Preferred name.
    v: First letter preferred name.
    w: First letter preferred or given name.
    d: Conditional: Either the preferred given or family name. Preferred name is given preference over given or family names.
    D: Conditional: Either the preferred given or family name. Family name is given preference over preferred or given names.

    Alternative component source

    A data source to use as the alternative component within the name formats. Possible use-cases include; providing a custom fully formatted name alternative to use in citations; a separate field for a users creditatons / post-nominal letters.

    Used by the following tokens

    a: Alternative value.
    A: First letter of alternative value.

    This one requires you to work out the conditionals if empty.

    i.e. (a|p) use the value of the Alt field unless the empty, then use the preferred name as a fallback (nickname has preference over firstname)

  • A vote in favour of adding a preferred or nickname option is the ability to use it with tokens. AFAICT it's not possible to add a Drupal token like [current-user:field_my_name:preferred], while it is possible to use [current-user:field_my_name:given]. Although I do see in https://www.drupal.org/project/name/issues/2775215 β†’ a workaround of hijacking an unused field, eg credentials.

Production build 0.71.5 2024