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
About this Presentation
 Duration:
40 minutes
 Audience:
Internationalization professionals
and the curious
 Presenter:
Addison Phillips
Director, Globalization Architecture
webMethods Inc.
 Topic:
Handling people’s names in software
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.
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”
 Wide variation in formats, handling, semantics, and
 Let’s examine:
 Considerations in input, validation, display and management
 Elements of a successful design
 Generalized data structures
 Integration problems
Getting the Right Mix
 Specialized applications are straightforward to create
 Design to cultural expectations
 No need to adjust formality, presentation, content, validation, or
 Fields are predetermined
 Generalized ones are difficult.
 Cultural expectations vary
 Presentation varies
 Level of formality varies
 Field values vary
Anatomy of a Name
 Given Name
 Salutation or Title
 Family Name
 Honorific
 “Middle” Name(s)
 Writing System
 Patronymic/Matronymic
 Generational Name
 Generational Suffix
 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
Cultural Variations: A Sampler
 Spanish/Latin American
 Icelandic
 Korean
 Russian
 Malaysian
 Indonesian
 Arabic
Application Problems…
 Length of fields
 Number of fields
 Arrangement of fields
 What goes in the fields
 Input Validation
 Level of Formality
 Sorting and presentation
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
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?
Consider Implementation Details
 Can we use separate forms for separate
 Separate sites?
 How do we choose the form? (Ask for country first?)
 Where is the data stored?
 Shared repository?
 Separate presentation from storage
Sparse Population
 Have more fields than you need
 Allow for sparse population (no NOT NULL fields?)
 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)
Do we mean ASCII-fication?
 Some Romanizations reflect an underlying
ASCII restriction.
 Printers, fonts, and technology (remember
the badge printer?)
 Databases
 Software
 Etc.
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??
Slightly More Complex
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
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.
Why Get Gender?
 Male and female names used in sentences require knowledge
of the gender.
 Display names for titles may be different depending on
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)
Searching and Organizing Lists
 Evil alphabet tab
 Provide for sorting of names using the local writing and indexing
system (Latin, Cyrillic, kana, etc.)
 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

What's in a Name? Handling Personal Names and …