- From: Cindy Conlin <ConlinC@ldschurch.org>
- Date: Wed, 3 Aug 2011 22:10:04 -0600
- To: "ishida@w3.org" <ishida@w3.org>
- CC: "www-international@w3.org" <www-international@w3.org>
- Message-ID: <AF3AE4D0B38F664D83E5D101DE6108030238E01886@MBX02.ldschurch.org>
Great job at capturing a lot of information in a very concise article. Here are my thoughts: 1. Mark suggested including some of the possible tasks a system must perform on names. Here are some of the additional tasks the system I work on at the LDS Church performs on names: a. Combine the names of multiple individuals for display, such as a couple (e.g. “Barak and Michelle Obama”) or a family with children. (“Obama: Barak, Michelle, Malia, and Sasha”) b. Romanize names using transliteration software. The ideal is for romanizations to be entered by users with the spelling they prefer, but in some cases this is not possible. Sometimes our automated Romanization is used for name matching purposes (especially if we need to match names across scripts, like government terrorist watch list software must do), and at other times it is a starting point for a data entry user who will correct the spelling. c. Match names with legal documents, such as passports or government issued ID cards, which sometimes requires storing multiple variations of the name. d. Guess at how a person’s name may change upon marriage, based on locale-specific rules and the husband and wife’s names before marriage. This guess is used as a starting point for data entry users who then adjust the name based on the couple’s choices. 2. The “Given name and patronymic” section mentions “Other cultures where a person has one given name followed by a patronymic include parts of Southern India, Malaysia and Indonesia.” Our data in these cultures has a large number of names that consist of a given name only, with no patronym. Some of our less-enlightened software requires family names, which creates significant problems in these cultures, as users enter garbage data like “.” or “Mr.” in the family name just to escape the field. (We may want to mention the problem of required fields somewhere in the “Implications for field design” section. IMHO, the only name field that can be required is a given name, because that is the only name that is consistently used across cultures). 3. The “Multiple family names” section mentions “Spanish-speaking people will commonly have two family names.” This is also common in Portuguese-speaking cultures. It’s also possible to have up to four family names in the name—sometimes people inherit names from all four grandparents; other times they have additional names from spouses. 4. The “Variant word forms” section gives an example of the gender-specific family names in Russia. Just wanted to mention that when you display the family name in a context where you are showing multiple people (such as in a display of a couple or a family including children), you need to display the plural ending of the family name, which can be different from both the masculine and feminine versions. 5. The “Inheritance of names” section has a paragraph about Spanish names. It may be helpful to note that Spanish and Portuguese cultures vary in the order in which they position the maternal and paternal family names. In general, most of the data I’ve observed has Portuguese cultures ordering the names “Maternal Paternal” and Spanish cultures ordering the names “Paternal Maternal”, but I understand that this varies even within Spanish cultures. 6. The 4th paragraph in the “Strategies for splitting up names” section has a typo—“sent” should be “send” in the sentence “Or perhaps it's because you want to sent them emails…” 7. The “Strategies for splitting up names” has a paragraph stating that if you want to sort Japanese names, you need an extra field to type how their name is pronounced. We’ve found that it’s been helpful to store a Kana version of names not only for sorting purposes, but also because a. The kana name is useful input into Romanization software. b. The kana name is helpful to other Japanese readers of the name who may not be familiar with the correct pronunciation. For example, to facilitate church members pronouncing each other’s names, we show the kana in parentheses after the Kanji name on our congregation lists. I’m not sure if this is a big help or only a little one—Richard, with your Japanese experience you’re in a better position than I am to comment on this. If you believe facilitating the pronunciation of the name to other Japanese readers is a valid reason a system should store a kana name, we may want to include it in the list of questions in after the statement “The decision about which is most appropriate will depend to some extent on what you are collecting people’s names for, and how you intend to use them. “ 8. The “Implications for character support” section doesn’t mention Japanese kana names, but I think it would be very helpful to readers to include it there, so readers understand that to fully support Japanese, they may actually need THREE script versions of the names. That section currently has an image showing two name fields: Name (in your alphabet) and Name (Latin alphabet)—it may be helpful to have an additional image showing three name fields: Name (Kanji), Name (Kana) and Name (Latin alphabet). From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of Mark Davis ? Sent: Wednesday, August 03, 2011 6:24 PM To: ishida@w3.org Cc: www-international@w3.org Subject: Re: Draft for review: Personal names around the world > http://www.w3.org/International/questions/qa-personal-names The overview of personal names is very useful. However, I think there are some problems with the guidance given in the section "implications for field design". Look at this from a functional approach. A particular system may need to do some of the following tasks: 1. Have a short, personal name, eg "Welcome back, Mark" 2. Have a relatively unique, informal name, eg "Mark Davis commented on your post". 3. Have a name to use in UIs that have "Sort by: Family Name" (meaning: or best equivalent) 4. Have a name to use in UIs that have "Sort by: Given Name" (meaning: or best equivalent) 5. Have a name for more formal contexts, such as a postal mailing, eg "Dr. Mark Davis" 6. Etc. I think having more such tasks listed in the document would help to motivate (and test) the recommendations give in the section "implications for field design". In particular, I think systems are often driven to asking for "Family Name" and "Given Name" because they can (or think they can) generate each of the forms needed for at least the tasks #1-#4. There is some tension, because you don't want to have a UI that asks for 8 different forms of a person's name; people find that onerous! NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Received on Thursday, 4 August 2011 14:56:28 UTC