What's in a Name Handling Personal Names and Information in a Global Application

1
What's in a Name? Handling Personal Names and
Information in a Global Application

• 26th Internationalization and Unicode Conference
• Addison P Phillips
• Director, Globalization Architecture

2
About this Presentation

• Duration 40 minutes
• Audience Internationalization
  professionals and the curious
• Presenter Addison Phillips Director,
  Globalization Architecture webMethods Inc.
• Topic Handling peoples names in software

3
Internationalization and Names

• International support for data types (numbers,
  dates, etc.) are generally built into your
  operating environment.
• Data structures present more complex
  internationalization design issues. Some of these
  structures include
• Postal Addresses
• Account Information
• Personal Preferences
• Etc.
• Personal names fall into this category.

4
Getting Personal Personal Names and Applications

• Names are strongly culturally linked.
• Not surprising names generally indicate lineage
  and other relationships between families, clans,
  and other tribal groupings.
• Wide variation in formats, handling, semantics,
  and presentation.
• Lets examine
• Considerations in input, validation, display and
  management
• Elements of a successful design
• Generalized data structures
• Integration problems

5
Getting the Right Mix

• Specialized applications are straightforward to
  create
• Design to cultural expectations
• No need to adjust formality, presentation,
  content, validation, or format
• Fields are predetermined
• Generalized ones are difficult.
• Cultural expectations vary
• Presentation varies
• Level of formality varies
• Field values vary

6
Anatomy of a Name

• Given Name
• Family Name
• Middle Name(s)
• Patronymic/Matronymic
• Generational Name
• Generational Suffix

• Salutation or Title
• Honorific
• Writing System
• Pronunciation1
• Personal Characters2
• Life Events
• Logins, Nicknames, Callsigns, UIDs, etc. etc.

Dr. Charles Augustus Phillips, Jr., DDS Guðríður
Magnusdóttir ???????2 Addison Phillips ?????????1
7
Cultural Variations A Sampler

• Spanish/Latin American
• Icelandic
• Korean
• Russian
• Malaysian
• Indonesian
• Arabic

8
Application Problems

• Length of fields
• Number of fields
• Arrangement of fields
• What goes in the fields
• Input Validation
• Level of Formality
• Sorting and presentation

9
The Integration Issue

• I want to take our customer list from country X
  and use it to generate a bulk mailing.
• Users from countries X, Y, and Z are all
  registering for my conference in Florida. My
  badge printer puts what on their badge?

10
Gather Requirements

• What does my application do?
• Simple return of string
• Used in more than one format (salutory, formal,
  etc.)
• Legal usage?
• What level of formality is needed?
• Need titles
• Need forms of address
• Do I have an address book or directory?
• Needs pronunciation and sorting information
• How does the user maintain the name?
• Life events?

11
Consider Implementation Details

• Can we use separate forms for separate
  countries/languages/cultures?
• Separate sites?
• How do we choose the form? (Ask for country
  first?)
• Where is the data stored?
• Shared repository?
• Separate presentation from storage

12
Sparse Population

• Have more fields than you need
• Allow for sparse population (no NOT NULL fields?)

13
Romanization

• Some applications require a change in writing
  system. Best to solicit this information from the
  user.
• Not necessarily when creating the record! Do it
  when you need it (sparse population)

14
Do we mean ASCII-fication?

• Some Romanizations reflect an underlying ASCII
  restriction.
• Printers, fonts, and technology (remember the
  badge printer?)
• Databases
• Software
• Etc.

15
Simple Solution

• Single name field, no validation, no parsing, no
  nothing
• Easiest to do
• Relies on the user to self-validate
• Useful for informal applications
• Tips
• Make the field really big (some people will want
  to type their whole name in)
• Really big 128 bytes??

16
Slightly More Complex
17
The Complete Package

• Given name
• Surname
• Additional Names
• Gender
• Pronunciation (2 fields, fixed length)
• Salutation (open enumeration)
• Generation (open enumeration)
• Nickname/Display Name
• ASCII given
• ASCII surname

18
Open Enumerations

• Some fields should be enumerated lists.
• Salutation
• English Mr., Ms., Mrs., Miss, Dr.
• French Monsieur, Madame, etc..
• Open enumeration allows you to add (and remove)
  values according to culture.
• Note Mr. and Monsieur are display names
  for the SAME enumerated value internally.

19
Why Get Gender?

• Male and female names used in sentences require
  knowledge of the gender.
• Display names for titles may be different
  depending on language.

20
Dealing with Lists

• Choosing the right display pattern
• Last, First has problems in some cultures!
• Use two (or more) fields whenever possible
• Deal with multiple names carefully
• Avoid recapitalization whenever possible.
• For Latin American and Spanish surnames, identify
  the maternal names (consider using the patronym
  field to store these)
• Allow for missing names or fields
• Single names (Prince, Sukarno)

21
Searching and Organizing Lists

• Evil alphabet tab
• Provide for sorting of names using the local
  writing and indexing system (Latin, Cyrillic,
  kana, etc.)

22
Summary

• Understand your requirements
• Understand how names vary across the world
• Use lots of fields
• Validate locally, display globally
• Allow sparse population
• Use open enumerations
• Provide for user-specific sorting