1 / 25

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

What's in a Name? Handling Personal Names and Information in a Global Application. 32nd Internationalization and Unicode Conference Addison Phillips Globalization Architect Lab126. Addison Phillips Globalization Architect Lab126 Chair – W3C Internationalization Core WG. Presenter.

demi
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related