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

in a Global Application

32nd Internationalization and Unicode ConferenceAddison Phillips

Globalization ArchitectLab126

Presenter

Addison PhillipsGlobalization ArchitectLab126

Chair – W3C Internationalization Core WG

Internationalization and Names

International support for data types (numbers, dates, etc.) is 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” groupings.

Wide variation in formats, handling, semantics, and presentation.

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 for personal names 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

Anatomy of a Name

Salutation or Title 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

風以里譜守味尊 2 　Addison Phillips フイリプスアジソン 1

Anatomy: Iceland

Given namePatronym

Guðríður Magnusdóttir

Magnus

Magnusdottir

Cultural Variations: A Sampler

Spanish/Latin AmericanIcelandicKoreanRussianMalaysianIndonesianThaiArabic

Yao Ming

Application Problems…

Length of fieldsNumber of fieldsArrangement of fieldsWhat goes in the fieldsInput ValidationLevel of FormalitySorting 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 badge?”

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◦Rendering in different contexts from that supplied

at inputHow does the user maintain the name?

◦Life events?

Consider Implementation Details

Can we use separate forms for separate countries/languages/cultures?◦Separate Web sites or software modules?◦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 needAllow for sparse population (no NOT NULL

fields?)

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)?

Do we mean ASCII-fication?

Some Romanizations reflect an underlying ASCII restriction.◦Printers, fonts, and technology

(remember the badge printer?)◦Databases◦Old 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 nameSurnameAdditional NamesGenderPronunciation (2 fields, fixed length)Salutation (open enumeration)Generation (open enumeration)Nickname/Display NameASCII givenASCII 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 language (Dr vs. Dra)

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

The Evil Alphabet Tab Interface◦Provide for sorting of names using the local

writing and indexing system (Latin, Cyrillic, kana, etc.)

Summary

Understand your requirementsUnderstand how names vary across the

worldUse lots of fieldsValidate locally, display globallyAllow sparse populationUse open enumerationsProvide for user-specific sorting

Questions? and Comments!