What's in a Name? Handling Personal Names and Information in a Global Application 32nd Internationalization and Unicode Conference Addison Phillips Globalization Architect Lab126

Presenter Addison Phillips Globalization Architect Lab126 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 ◦ Pronunciation 1 ◦ Personal Characters 2 Life Events Logins, Nicknames, Callsigns, UIDs, etc. etc. Dr. Charles Augustus Phillips, Jr., DDS 風以里譜守味尊 2 Addison Phillips フイリプスアジソン 1

Anatomy: Iceland Given name Patronym Guðríður Magnusdótt ir Magnus Magnusdottir

Cultural Variations: A Sampler Spanish/Latin American Icelandic Korean Russian Malaysian Indonesian Thai Arabic

Yao Ming

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 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 input How 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 need Allow 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 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 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 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

 Questions? and Comments!