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 people’s 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. • Let’s 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. 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. Anatomy of a Name Dr.CharlesAugustusPhillips, Jr., DDS Guðríður Magnusdóttir 風以里譜守味尊2Addison 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