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 32nd Internationalization and Unicode Conference Addison Phillips Globalization Architect Lab126

2. Addison PhillipsGlobalization ArchitectLab126Chair – W3C Internationalization Core WG Presenter

3. 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. Internationalization and Names

4. 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 Personal: Personal Names and Applications

5. 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 Getting the Right Mix

6. 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. CharlesAugustusPhillips, Jr., DDS 風以里譜守味尊2Addison Phillips フイリプスアジソン1 Anatomy of a Name

7. Given name • Patronym GuðríðurMagnusdóttir Magnusdottir Magnus Anatomy: Iceland

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

9. Yao Ming

10. Length of fields • Number of fields • Arrangement of fields • What goes in the fields • Input Validation • Level of Formality • Sorting and presentation Application Problems…

11. “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?” The Integration Issue

12. 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? Gather Requirements

13. 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 Consider Implementation Details

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

15. 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)? Romanization

16. Some Romanizations reflect an underlying ASCII restriction. • Printers, fonts, and technology (remember the badge printer?) • Databases • Old software • Etc. Do we mean ASCII-fication?

17. 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?? Simple Solution

18. Slightly More Complex

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

20. 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. Open Enumerations

21. 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) Why Get Gender?

22. 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) Dealing with Lists

23. The Evil Alphabet Tab Interface • Provide for sorting of names using the local writing and indexing system (Latin, Cyrillic, kana, etc.) Searching and Organizing Lists

24. 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 Summary

25. Questions? and Comments!